--- /dev/null
+From 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 Mon Sep 17 00:00:00 2001
+From: Patrick Roy <roypat@amazon.co.uk>
+Date: Tue, 1 Oct 2024 09:00:41 +0100
+Subject: secretmem: disable memfd_secret() if arch cannot set direct map
+
+From: Patrick Roy <roypat@amazon.co.uk>
+
+commit 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 upstream.
+
+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/
+
+Link: https://lkml.kernel.org/r/20241001080056.784735-1-roypat@amazon.co.uk
+Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
+Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
+Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
+Cc: Alexander Graf <graf@amazon.com>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: James Gowans <jgowans@amazon.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/secretmem.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/secretmem.c
++++ b/mm/secretmem.c
+@@ -234,7 +234,7 @@ SYSCALL_DEFINE1(memfd_secret, unsigned i
+ /* make sure local flags do not confict with global fcntl.h */
+ BUILD_BUG_ON(SECRETMEM_FLAGS_MASK & O_CLOEXEC);
+
+- if (!secretmem_enable)
++ if (!secretmem_enable || !can_set_direct_map())
+ return -ENOSYS;
+
+ if (flags & ~(SECRETMEM_FLAGS_MASK | O_CLOEXEC))
+@@ -278,7 +278,7 @@ static int secretmem_init(void)
+ {
+ int ret = 0;
+
+- if (!secretmem_enable)
++ if (!secretmem_enable || !can_set_direct_map())
+ return ret;
+
+ secretmem_mnt = kern_mount(&secretmem_fs);
--- /dev/null
+From 31db78a4923ef5e2008f2eed321811ca79e7f71b Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Tue, 19 Sep 2023 08:34:15 +0200
+Subject: wifi: mac80211: fix potential key use-after-free
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 31db78a4923ef5e2008f2eed321811ca79e7f71b upstream.
+
+When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
+but returns 0 due to KRACK protection (identical key reinstall),
+ieee80211_gtk_rekey_add() will still return a pointer into the
+key, in a potential use-after-free. This normally doesn't happen
+since it's only called by iwlwifi in case of WoWLAN rekey offload
+which has its own KRACK protection, but still better to fix, do
+that by returning an error code and converting that to success on
+the cfg80211 boundary only, leaving the error for bad callers of
+ieee80211_gtk_rekey_add().
+
+Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
+Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+[ Sherry: bp to fix CVE-2023-52530, resolved minor conflicts in
+ net/mac80211/cfg.c because of context change due to missing commit
+ 23a5f0af6ff4 ("wifi: mac80211: remove cipher scheme support")
+ ccdde7c74ffd ("wifi: mac80211: properly implement MLO key handling")]
+Signed-off-by: Sherry Yang <sherry.yang@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mac80211/cfg.c | 3 +++
+ net/mac80211/key.c | 2 +-
+ 2 files changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/mac80211/cfg.c
++++ b/net/mac80211/cfg.c
+@@ -511,6 +511,9 @@ static int ieee80211_add_key(struct wiph
+ sta->cipher_scheme = cs;
+
+ err = ieee80211_key_link(key, sdata, sta);
++ /* KRACK protection, shouldn't happen but just silently accept key */
++ if (err == -EALREADY)
++ err = 0;
+
+ out_unlock:
+ mutex_unlock(&local->sta_mtx);
+--- a/net/mac80211/key.c
++++ b/net/mac80211/key.c
+@@ -843,7 +843,7 @@ int ieee80211_key_link(struct ieee80211_
+ */
+ if (ieee80211_key_identical(sdata, old_key, key)) {
+ ieee80211_key_free_unused(key);
+- ret = 0;
++ ret = -EALREADY;
+ goto out;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
