| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-50182: secretmem: disable memfd_secret() if arch cannot set direct map |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| secretmem: disable memfd_secret() if arch cannot set direct map |
| |
| Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This |
| is the case for example on some arm64 configurations, where marking 4k |
| PTEs in the direct map not present can only be done if the direct map is |
| set up at 4k granularity in the first place (as ARM's break-before-make |
| semantics do not easily allow breaking apart large/gigantic pages). |
| |
| More precisely, on arm64 systems with !can_set_direct_map(), |
| set_direct_map_invalid_noflush() is a no-op, however it returns success |
| (0) instead of an error. This means that memfd_secret will seemingly |
| "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), |
| but it does not actually achieve its goal of removing its memory from the |
| direct map. |
| |
| Note that with this patch, memfd_secret() will start erroring on systems |
| where can_set_direct_map() returns false (arm64 with |
| CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and |
| CONFIG_KFENCE=n), but that still seems better than the current silent |
| failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most |
| arm64 systems actually have a working memfd_secret() and aren't be |
| affected. |
| |
| From going through the iterations of the original memfd_secret patch |
| series, it seems that disabling the syscall in these scenarios was the |
| intended behavior [1] (preferred over having |
| set_direct_map_invalid_noflush return an error as that would result in |
| SIGBUSes at page-fault time), however the check for it got dropped between |
| v16 [2] and v17 [3], when secretmem moved away from CMA allocations. |
| |
| [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ |
| [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t |
| [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/ |
| |
| The Linux kernel CVE team has assigned CVE-2024-50182 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.14 with commit 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 and fixed in 5.15.169 with commit d0ae6ffa1aeb297aef89f49cfb894a83c329ebad |
| Issue introduced in 5.14 with commit 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 and fixed in 6.1.113 with commit 5ea0b7af38754d2b45ead9257bca47e84662e926 |
| Issue introduced in 5.14 with commit 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 and fixed in 6.6.57 with commit 7caf966390e6e4ebf42775df54e7ee1f280ce677 |
| Issue introduced in 5.14 with commit 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 and fixed in 6.11.4 with commit 757786abe4547eb3d9d0e8350a63bdb0f9824af2 |
| Issue introduced in 5.14 with commit 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 and fixed in 6.12 with commit 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2024-50182 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| mm/secretmem.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad |
| https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926 |
| https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677 |
| https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2 |
| https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6 |
