linux-cve-announce - CVE-2024-50182: secretmem: disable memfd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2024110833-CVE-2024-50182-0fe4@gregkh>
Date: Fri,  8 Nov 2024 06:38:35 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.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 1507f51255c9 and fixed in 5.15.169 with commit d0ae6ffa1aeb
	Issue introduced in 5.14 with commit 1507f51255c9 and fixed in 6.1.113 with commit 5ea0b7af3875
	Issue introduced in 5.14 with commit 1507f51255c9 and fixed in 6.6.57 with commit 7caf966390e6
	Issue introduced in 5.14 with commit 1507f51255c9 and fixed in 6.11.4 with commit 757786abe454
	Issue introduced in 5.14 with commit 1507f51255c9 and fixed in 6.12-rc3 with commit 532b53cebe58

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