From ca12adea45f42c70e5ec6bfacb249a56a52c5b1f Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 18 Oct 2024 11:00:15 +0200 Subject: [PATCH] 5.15-stable patches added patches: secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch wifi-mac80211-fix-potential-key-use-after-free.patch --- ...secret-if-arch-cannot-set-direct-map.patch | 76 +++++++++++++++++++ queue-5.15/series | 2 + ...211-fix-potential-key-use-after-free.patch | 58 ++++++++++++++ 3 files changed, 136 insertions(+) create mode 100644 queue-5.15/secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch create mode 100644 queue-5.15/wifi-mac80211-fix-potential-key-use-after-free.patch diff --git a/queue-5.15/secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch b/queue-5.15/secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch new file mode 100644 index 00000000000..b1220cff8f1 --- /dev/null +++ b/queue-5.15/secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch @@ -0,0 +1,76 @@ +From 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 Mon Sep 17 00:00:00 2001 +From: Patrick Roy +Date: Tue, 1 Oct 2024 09:00:41 +0100 +Subject: secretmem: disable memfd_secret() if arch cannot set direct map + +From: Patrick Roy + +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 +Reviewed-by: Mike Rapoport (Microsoft) +Cc: Alexander Graf +Cc: David Hildenbrand +Cc: James Gowans +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Mike Rapoport (Microsoft) +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/series b/queue-5.15/series index 6616871a7d8..cb2bd837a89 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -28,3 +28,5 @@ net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-p irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch fat-fix-uninitialized-variable.patch mm-swapfile-skip-hugetlb-pages-for-unuse_vma.patch +secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch +wifi-mac80211-fix-potential-key-use-after-free.patch diff --git a/queue-5.15/wifi-mac80211-fix-potential-key-use-after-free.patch b/queue-5.15/wifi-mac80211-fix-potential-key-use-after-free.patch new file mode 100644 index 00000000000..a18a3f671b8 --- /dev/null +++ b/queue-5.15/wifi-mac80211-fix-potential-key-use-after-free.patch @@ -0,0 +1,58 @@ +From 31db78a4923ef5e2008f2eed321811ca79e7f71b Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Tue, 19 Sep 2023 08:34:15 +0200 +Subject: wifi: mac80211: fix potential key use-after-free + +From: Johannes Berg + +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 +Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +[ 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 +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + -- 2.47.3