- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/4] Fix CVE-2026-68096
by Yi Yang 08 Sep '26

08 Sep '26

The following four patches are used to fix the CVE-2026-68096 vulnerability: Jeff Layton (1): audit: widen ino fields to u64 NeilBrown (1): VFS/audit: introduce kern_path_parent() for audit Ricardo Robaina (2): audit: use 'unsigned int' instead of 'unsigned' audit: fix recursive locking deadlock in audit_dupe_exe() fs/namei.c | 43 ++++++++++++++++++++++++++++++++++++++ include/linux/audit.h | 6 +++--- include/linux/audit_arch.h | 12 +++++------ include/linux/namei.h | 1 + kernel/audit.c | 2 +- kernel/audit.h | 32 ++++++++++++++++------------ kernel/audit_fsnotify.c | 39 +++++++++++++++++++++------------- kernel/audit_tree.c | 2 +- kernel/audit_watch.c | 42 ++++++++++++++++++++++++------------- kernel/auditfilter.c | 17 ++++++++------- kernel/auditsc.c | 6 +++--- lib/compat_audit.c | 12 +++++------ 12 files changed, 144 insertions(+), 70 deletions(-) -- 2.25.1

2 5

[PATCH OLK-5.10] wifi: cfg80211: use wiphy work for socket owner autodisconnect
by Jinjiang Tu 08 Sep '26

08 Sep '26

mainline inclusion from mainline-v7.2-rc4 commit 0c2ed186bbe14304415476d6707b747dddcd8583 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17056 CVE: CVE-2026-68404 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev. Fixes: bd2522b16884 ("cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT") Suggested-by: Johannes Berg <johannes(a)sipsolutions.net> Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang <zzzccc427(a)gmail.com> Link: https://patch.msgid.link/20260706152418.779226-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/wireless/core.c include/net/cfg80211.h net/wireless/core.h net/wireless/nl80211.c net/wireless/sme.c [Upstream commit 0c2ed186bbe14 ("wifi: cfg80211: use wiphy work for socket owner autodisconnect") converts wdev->disconnect_wk from plain work_struct to wiphy_work and relies on wiphy_lock/guard(wiphy) which were introduced in 6.x. OLK-5.10 (5.10 base) does not carry the wiphy_work framework, so this backport keeps disconnect_wk as plain work_struct and applies the equivalent fix in two places: 1. In __cfg80211_unregister_wdev(): keep the existing cancel/flush position (after list_del_rcu() + synchronize_rcu()) but switch flush_work() to cancel_work_sync(). The position must be after synchronize_rcu(): a NETLINK_URELEASE notifier that entered the RCU reader before list_del_rcu will schedule_work(disconnect_wk) before its reader exits, and only a post-synchronize_rcu cancel catches that work. cancel_work_sync also dequeues pending work that flush_work would have executed needlessly. This matches the upstream semantic "cancel after list_del_rcu and synchronize_net". 2. In NETDEV_GOING_DOWN: cancel_work_sync(&wdev->disconnect_wk) after cfg80211_leave() to drop any disconnect_wk queued by a URELEASE notifier before teardown. olk5.10 was missing this cancel entirely. The upstream commit message mentions that wiphy_work is chosen to avoid "a cancel_work_sync() vs. worker locking concern". That concern is specific to the 6.x lock structure where disconnect_wk's work function takes wiphy_lock and teardown holds wiphy_lock while calling cancel_work_sync (the deadlock pattern described in commit 2b0eab425e1f "wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock"). olk5.10's lock structure is different: cfg80211_autodisconnect_wk only takes wdev->mtx (wdev_lock), and the two cancel_work_sync() call sites added here hold RTNL but not wdev->mtx. There is no lock L that both cancel_work_sync() and the work function need, so the deadlock condition does not apply. ] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- net/wireless/core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/wireless/core.c b/net/wireless/core.c index c6c5dd4e3520..1a36b52ed744 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -1132,9 +1132,8 @@ static void __cfg80211_unregister_wdev(struct wireless_dev *wdev, bool sync) kfree_sensitive(wdev->wext.keys); wdev->wext.keys = NULL; #endif - /* only initialized if we have a netdev */ if (wdev->netdev) - flush_work(&wdev->disconnect_wk); + cancel_work_sync(&wdev->disconnect_wk); cfg80211_cqm_config_free(wdev); } @@ -1340,6 +1339,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb, break; case NETDEV_GOING_DOWN: cfg80211_leave(rdev, wdev); + if (wdev->netdev) + cancel_work_sync(&wdev->disconnect_wk); break; case NETDEV_DOWN: cfg80211_update_iface_num(rdev, wdev->iftype, -1); -- 2.43.0

2 1

[PATCH OLK-5.10] sctp: validate stream count in sctp_process_strreset_inreq()
by Jinjiang Tu 08 Sep '26

08 Sep '26

From: "Cen Zhang (Microsoft)" <blbllhy(a)gmail.com> stable inclusion from stable-v5.10.265 commit 61327d8e7cfb0259d527be17202630f556213249 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17149 CVE: CVE-2026-68315 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 18ae07691d43183d270de8be9dc8e027906015d9 ] When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer. Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter") Reported-by: AutonomousCodeSecurity(a)microsoft.com Closes: https://lore.kernel.org/all/20260707203215.2752-1-blbllhy@gmail.com/ Suggested-by: Xin Long <lucien.xin(a)gmail.com> Signed-off-by: Cen Zhang (Microsoft) <blbllhy(a)gmail.com> Acked-by: Xin Long <lucien.xin(a)gmail.com> Link: https://patch.msgid.link/20260710010718.20318-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- net/sctp/stream.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/sctp/stream.c b/net/sctp/stream.c index ee6514af830f..73c212ae69d8 100644 --- a/net/sctp/stream.c +++ b/net/sctp/stream.c @@ -308,7 +308,8 @@ int sctp_send_reset_streams(struct sctp_association *asoc, goto out; param_len += str_nums * sizeof(__u16) + - sizeof(struct sctp_strreset_inreq); + (out ? sizeof(struct sctp_strreset_inreq) + : sizeof(struct sctp_strreset_outreq)); } if (param_len > SCTP_MAX_CHUNK_LEN - @@ -639,6 +640,9 @@ struct sctp_chunk *sctp_process_strreset_inreq( nums = (ntohs(param.p->length) - sizeof(*inreq)) / sizeof(__u16); str_p = inreq->list_of_streams; + if (nums * sizeof(__u16) + sizeof(struct sctp_strreset_outreq) > + SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_reconf_chunk)) + goto out; for (i = 0; i < nums; i++) { if (ntohs(str_p[i]) >= stream->outcnt) { result = SCTP_STRRESET_ERR_WRONG_SSN; -- 2.43.0

2 1

[PATCH OLK-5.10] sctp: validate cookie AUTH state before use
by Jinjiang Tu 08 Sep '26

08 Sep '26

From: Jérémy Jean <Jeremy.Jean(a)oss.cyber.gouv.fr> mainline inclusion from mainline-v7.2 commit 3dbb44d88b1e94dd31fe43588af7437b34b44d56 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18398 CVE: CVE-2026-74752 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays. A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain. Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Signed-off-by: Jérémy Jean <Jeremy.Jean(a)oss.cyber.gouv.fr> Acked-by: Xin Long <lucien.xin(a)gmail.com> Link: https://patch.msgid.link/20260804200042.2412009-1-Jeremy.Jean@oss.cyber.gou… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: include/net/sctp/auth.h net/sctp/auth.c [Backport of upstream 3dbb44d88b1e adding sctp_auth_verify_cookie_params() to validate the cookie's RANDOM/HMACS/CHUNKS parameters before they are restored into an association. Two helpers used by the new function are provided by later mainline refactors absent on this tree and are replaced with in-tree equivalents: - sctp_sk(ep->base.sk)->cookie_auth_enable (from 2f3dd6ec901f2, which replaces sp->hmac with a bool) becomes sctp_sk(ep->base.sk)->hmac, whose non-NULL value keeps the same "cookie HMAC auth enabled" meaning already used by sctp_pack_cookie()/sctp_unpack_cookie(); - sctp_hmac_supported(hmac_id) (from bf40785fa437c) becomes the equivalent "hmac_id >= SCTP_AUTH_NUM_HMACS || !sctp_hmac_list[hmac_id].hmac_name" check matching auth.c style. In auth.h the new declaration and the struct sctp_cookie forward declaration are added while the downstream crypto_shash, init_hmacs, destroy_hmacs declarations and the non-const sctp_auth_get_hmac()/ sctp_auth_asoc_get_hmac() signatures (predating the const qualifiers of the upstream refactors) are preserved. The full validation logic is retained and is semantically equivalent to upstream.] Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- include/net/sctp/auth.h | 3 ++ net/sctp/auth.c | 76 ++++++++++++++++++++++++++++++++++++++++ net/sctp/sm_make_chunk.c | 3 ++ 3 files changed, 82 insertions(+) diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h index d4b3b2dcd15b..c2399fb17889 100644 --- a/include/net/sctp/auth.h +++ b/include/net/sctp/auth.h @@ -23,6 +23,7 @@ struct sctp_association; struct sctp_authkey; struct sctp_hmacalgo; struct crypto_shash; +struct sctp_cookie; /* * Define a generic struct that will hold all the info @@ -77,6 +78,8 @@ struct sctp_shared_key *sctp_auth_get_shkey( int sctp_auth_asoc_copy_shkeys(const struct sctp_endpoint *ep, struct sctp_association *asoc, gfp_t gfp); +bool sctp_auth_verify_cookie_params(const struct sctp_endpoint *ep, + const struct sctp_cookie *cookie); int sctp_auth_init_hmacs(struct sctp_endpoint *ep, gfp_t gfp); void sctp_auth_destroy_hmacs(struct crypto_shash *auth_hmacs[]); struct sctp_hmac *sctp_auth_get_hmac(__u16 hmac_id); diff --git a/net/sctp/auth.c b/net/sctp/auth.c index 34964145514e..e317a2df046d 100644 --- a/net/sctp/auth.c +++ b/net/sctp/auth.c @@ -376,6 +376,82 @@ int sctp_auth_asoc_copy_shkeys(const struct sctp_endpoint *ep, return -ENOMEM; } +static bool sctp_auth_chunk_id_forbidden(__u8 chunk_id) +{ + switch (chunk_id) { + case SCTP_CID_INIT: + case SCTP_CID_INIT_ACK: + case SCTP_CID_SHUTDOWN_COMPLETE: + case SCTP_CID_AUTH: + return true; + default: + return false; + } +} + +/* Verify AUTH parameters copied from a state cookie before they are restored + * into an association. When cookie authentication is disabled these fields + * are peer-controlled, so they must satisfy the same constraints as locally + * generated AUTH parameters. + */ +bool sctp_auth_verify_cookie_params(const struct sctp_endpoint *ep, + const struct sctp_cookie *cookie) +{ + const struct sctp_paramhdr *random; + const struct sctp_hmac_algo_param *hmacs; + const struct sctp_chunks_param *chunks; + u16 hmacs_len, chunks_len; + u16 n_hmacs, n_chunks, i; + bool has_sha1 = false; + + if (sctp_sk(ep->base.sk)->hmac || !ep->auth_enable) + return true; + + random = (const struct sctp_paramhdr *)cookie->auth_random; + if (random->type != SCTP_PARAM_RANDOM || + ntohs(random->length) != sizeof(*random) + SCTP_AUTH_RANDOM_LENGTH) + return false; + + hmacs = (const struct sctp_hmac_algo_param *)cookie->auth_hmacs; + hmacs_len = ntohs(hmacs->param_hdr.length); + if (hmacs->param_hdr.type != SCTP_PARAM_HMAC_ALGO || + hmacs_len < sizeof(struct sctp_paramhdr) + + sizeof(hmacs->hmac_ids[0]) || + hmacs_len > sizeof(cookie->auth_hmacs) || + (hmacs_len - sizeof(struct sctp_paramhdr)) % + sizeof(hmacs->hmac_ids[0])) + return false; + + n_hmacs = (hmacs_len - sizeof(struct sctp_paramhdr)) / + sizeof(hmacs->hmac_ids[0]); + for (i = 0; i < n_hmacs; i++) { + u16 hmac_id = ntohs(hmacs->hmac_ids[i]); + + if (hmac_id >= SCTP_AUTH_NUM_HMACS || + !sctp_hmac_list[hmac_id].hmac_name) + return false; + if (hmac_id == SCTP_AUTH_HMAC_ID_SHA1) + has_sha1 = true; + } + if (!has_sha1) + return false; + + chunks = (const struct sctp_chunks_param *)cookie->auth_chunks; + chunks_len = ntohs(chunks->param_hdr.length); + if (chunks->param_hdr.type != SCTP_PARAM_CHUNKS || + chunks_len < sizeof(struct sctp_paramhdr) || + chunks_len > sizeof(cookie->auth_chunks)) + return false; + + n_chunks = chunks_len - sizeof(struct sctp_paramhdr); + for (i = 0; i < n_chunks; i++) { + if (sctp_auth_chunk_id_forbidden(chunks->chunks[i])) + return false; + } + + return true; +} + /* Public interface to create the association shared key. * See code above for the algorithm. diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 9ee24c361416..07b2a0c97f4a 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -1828,6 +1828,9 @@ struct sctp_association *sctp_unpack_cookie( /* Set up our peer's port number. */ retval->peer.port = ntohs(chunk->sctp_hdr->source); + if (!sctp_auth_verify_cookie_params(ep, bear_cookie)) + goto malformed; + /* Populate the association from the cookie. */ memcpy(&retval->c, bear_cookie, sizeof(*bear_cookie)); -- 2.43.0

2 1

[PATCH OLK-5.10] sctp: validate Adaptation Indication parameter length
by Jinjiang Tu 08 Sep '26

08 Sep '26

From: Charles Vosburgh <trilobyte777(a)gmail.com> stable inclusion from stable-v5.10.265 commit fa7861ddbe3b525b5d541c15c3953d3569e6eb0e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18468 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 74b21f52c5c5a71a05c0ff70e513f4f04ff28b17 upstream. The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present. sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes. Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Charles Vosburgh <trilobyte777(a)gmail.com> Acked-by: Xin Long <lucien.xin(a)gmail.com> Link: https://patch.msgid.link/20260727-sctp-adaptation-length-v1-1-0ab58b2810a5@… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- net/sctp/sm_make_chunk.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 07b2a0c97f4a..b6f88f59bc7e 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -2150,7 +2150,13 @@ static enum sctp_ierror sctp_verify_param(struct net *net, case SCTP_PARAM_HEARTBEAT_INFO: case SCTP_PARAM_UNRECOGNIZED_PARAMETERS: case SCTP_PARAM_ECN_CAPABLE: + break; case SCTP_PARAM_ADAPTATION_LAYER_IND: + if (ntohs(param.p->length) != sizeof(*param.aind)) { + sctp_process_inv_paramlength(asoc, param.p, + chunk, err_chunk); + retval = SCTP_IERROR_ABORT; + } break; case SCTP_PARAM_SUPPORTED_EXT: -- 2.43.0

2 1

[PATCH OLK-6.6] mm/huge_memory: fix huge_zero_pfn race
by Zhang Qilong 08 Sep '26

08 Sep '26

From: "Lorenzo Stoakes (ARM)" <ljs(a)kernel.org> stable inclusion from stable-v6.6.153 commit f3a874a903053c53fb53ba287ea9eacda69c68e8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18287 CVE: CVE-2026-74632 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb upstream. Patch series "mm/huge_memory: fix huge_zero_pfn race", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and huge_zero_refcount writes. * Be set non-zero only AFTER huge_zero_[pfn, folio] are set to valid values so installation of the huge zero folio on read page fault ensures concurrent is_huge_zero_*() calls correctly identify the huge zero folio. * Be set zero only BEFORE huge_zero_[pfn, folio] are set to NULL and ~0UL respectively, and atomically. Establish these by: * Only setting huge_zero_refcount to zero or an absolute value in the huge_zero_lock critical section in get_huge_zero_folio() and shrink_huge_zero_folio_scan(), and always updating atomically there and elsewhere. * Using atomic_set_release(&huge_zero_refcount) in get_huge_zero_folio() after huge_zero_[pfn, folio] are set. This is paired with atomic_inc_not_zero() to ensure atomic_inc_not_zero() only observes a non-zero value if huge_zero_[pfn, folio] are set. * Using atomic_cmpxchg() in shrink_huge_zero_folio_scan() (as before) to ensure that it is set zero only when equal to 1 and set atomically. * atomic_cmpxchg() being fully ordered ensures this is done prior to huge_zero_[folio, pfn] being set to NULL and ~0UL respectively. Eliminate the retry loop in get_huge_zero_folio() as the atomic_cmpxchg() in shrink_huge_zero_folio_scan() is now performed under the lock, and replace with an equally locked atomic_inc() to set the reference count should the caller be raced on huge zero folio installation. folio_put() naturally implies a full memory barrier so its ordering is maintained correctly. The huge zero folio also cannot be released except when the shrinker does so as it is non-LRU and non-rmappable. Note that only the huge zero shrinker (via shrink_huge_zero_folio_scan()) can actually set huge_zero_refcount to zero, which is the count of mm's which have at least one huge zero folio installed plus one shrinker pin. Additionally convert a BUG_ON() to a VM_WARN_ON_ONCE(). Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-0-c5d8a41b317f… Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-1-c5d8a41b317f… Fixes: 3b77e8c8cde5 ("mm/thp: make is_huge_zero_pmd() safe and quicker") Signed-off-by: Lorenzo Stoakes (ARM) <ljs(a)kernel.org> Reported-by: Hengbin Zhang <uqbarz(a)gmail.com> Closes: https://lore.kernel.org/linux-mm/20260727154001.4102341-1-uqbarz@gmail.com/ Suggested-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Dev Jain <dev.jain(a)arm.com> Cc: Hannes Reinecke <hare(a)suse.de> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kiryl Shutsemau <kas(a)kernel.org> Cc: Lance Yang <lance.yang(a)linux.dev> Cc: Liam R. Howlett <liam(a)infradead.org> Cc: Nico Pache <npache(a)redhat.com> Cc: Pankaj Raghav <p.raghav(a)samsung.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Yang Shi <shy828301(a)gmail.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> [ adapted folio API (`huge_zero_folio`, `folio_pfn`, `folio_put`) to pre-6.11 page naming (`huge_zero_page`, `page_to_pfn`, `__free_pages`) ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: mm/huge_memory.c [Just shrinker name conflicts] Signed-off-by: Zhang Qilong <zhangqilong3(a)huawei.com> --- mm/huge_memory.c | 43 +++++++++++++++++++++++++++++-------------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index bb884be9b761..952abb6d00a7 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -38,10 +38,11 @@ #include <linux/numa.h> #include <linux/page_owner.h> #include <linux/sched/sysctl.h> #include <linux/memory-tiers.h> #include <linux/compat.h> +#include <linux/cleanup.h> #include <asm/tlb.h> #include <asm/pgalloc.h> #include "internal.h" #include "swap.h" @@ -75,10 +76,11 @@ static unsigned long deferred_split_count(struct shrinker_v2 *shrink, struct shrink_control *sc); static unsigned long deferred_split_scan(struct shrinker_v2 *shrink, struct shrink_control *sc); static atomic_t huge_zero_refcount; +static DEFINE_SPINLOCK(huge_zero_lock); struct page *huge_zero_page __read_mostly; unsigned long huge_zero_pfn __read_mostly = ~0UL; unsigned long huge_anon_orders_always __read_mostly; unsigned long huge_anon_orders_madvise __read_mostly; unsigned long huge_anon_orders_inherit __read_mostly; @@ -196,31 +198,37 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma, } static bool get_huge_zero_page(void) { struct page *zero_page; -retry: + + /* Paired with atomic_set_release(). */ if (likely(atomic_inc_not_zero(&huge_zero_refcount))) return true; zero_page = alloc_pages((GFP_TRANSHUGE | __GFP_ZERO) & ~__GFP_MOVABLE, HPAGE_PMD_ORDER); if (!zero_page) { count_vm_event(THP_ZERO_PAGE_ALLOC_FAILED); return false; } - preempt_disable(); - if (cmpxchg(&huge_zero_page, NULL, zero_page)) { - preempt_enable(); + + /* Paired with critical section in shrink_huge_zero_page_scan(). */ + spin_lock(&huge_zero_lock); + if (huge_zero_page) { + /* Somebody else already installed it. */ + atomic_inc(&huge_zero_refcount); + spin_unlock(&huge_zero_lock); __free_pages(zero_page, compound_order(zero_page)); - goto retry; + return true; } + WRITE_ONCE(huge_zero_page, zero_page); WRITE_ONCE(huge_zero_pfn, page_to_pfn(zero_page)); + /* Paired with atomic_inc_not_zero(). +1 for shrinker pin. */ + atomic_set_release(&huge_zero_refcount, 2); + spin_unlock(&huge_zero_lock); - /* We take additional reference here. It will be put back by shrinker */ - atomic_set(&huge_zero_refcount, 2); - preempt_enable(); count_vm_event(THP_ZERO_PAGE_ALLOC); return true; } static void put_huge_zero_page(void) @@ -260,19 +268,26 @@ static unsigned long shrink_huge_zero_page_count(struct shrinker_v2 *shrink, } static unsigned long shrink_huge_zero_page_scan(struct shrinker_v2 *shrink, struct shrink_control *sc) { - if (atomic_cmpxchg(&huge_zero_refcount, 1, 0) == 1) { - struct page *zero_page = xchg(&huge_zero_page, NULL); - BUG_ON(zero_page == NULL); + struct page *zero_page; + + /* Paired with critical section in get_huge_zero_page(). */ + scoped_guard(spinlock, &huge_zero_lock) { + /* Paired with atomic_inc_not_zero() in get_huge_zero_page(). */ + if (atomic_cmpxchg(&huge_zero_refcount, 1, 0) != 1) + return 0; + + zero_page = huge_zero_page; + VM_WARN_ON_ONCE(!zero_page); + WRITE_ONCE(huge_zero_page, NULL); WRITE_ONCE(huge_zero_pfn, ~0UL); - __free_pages(zero_page, compound_order(zero_page)); - return HPAGE_PMD_NR; } - return 0; + __free_pages(zero_page, compound_order(zero_page)); + return HPAGE_PMD_NR; } static struct shrinker_v2 *huge_zero_page_shrinker; #ifdef CONFIG_SYSFS -- 2.43.0

2 1

[PATCH OLK-6.6] net: usb: ipheth: fix carrier_work UAF on disconnect
by Zhang Qilong 08 Sep '26

08 Sep '26

From: Doruk Tan Ozturk <doruk(a)0sec.ai> stable inclusion from stable-v6.12.104 commit d07133fe1befae9a1e4c4c5e46ef0b73d2992020 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18212 CVE: CVE-2026-74677 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit fde39b8a521780391fb4e5bda2c0aa4928947f12 upstream. ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: else schedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai) Fixes: bb1b40c7cb86 ("usbnet: ipheth: prevent TX queue timeouts when device not ready") Cc: stable(a)vger.kernel.org Signed-off-by: Doruk Tan Ozturk <doruk(a)0sec.ai> Link: https://patch.msgid.link/20260802120602.42595-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Qilong <zhangqilong3(a)huawei.com> --- drivers/net/usb/ipheth.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c index a19789b57190..a86d0a4dbd28 100644 --- a/drivers/net/usb/ipheth.c +++ b/drivers/net/usb/ipheth.c @@ -488,20 +488,25 @@ static int ipheth_open(struct net_device *net) retval = ipheth_rx_submit(dev, GFP_KERNEL); if (retval) return retval; + enable_delayed_work(&dev->carrier_work); schedule_delayed_work(&dev->carrier_work, IPHETH_CARRIER_CHECK_TIMEOUT); return retval; } static int ipheth_close(struct net_device *net) { struct ipheth_device *dev = netdev_priv(net); netif_stop_queue(net); - cancel_delayed_work_sync(&dev->carrier_work); + /* A TX URB can still complete with an error after this point and + * try to re-arm the carrier work. Disable it instead of cancelling + * it, so that such a schedule_delayed_work() is a no-op. + */ + disable_delayed_work_sync(&dev->carrier_work); return 0; } static netdev_tx_t ipheth_tx(struct sk_buff *skb, struct net_device *net) { @@ -631,10 +636,14 @@ static int ipheth_probe(struct usb_interface *intf, dev->rx_buf_len = IPHETH_RX_BUF_SIZE_NCM; dev->rcvbulk_callback = ipheth_rcvbulk_callback_ncm; } INIT_DELAYED_WORK(&dev->carrier_work, ipheth_carrier_check_work); + /* Armed only between ipheth_open() and ipheth_close(). Start out + * disabled so the enable/disable counts balance from the first open. + */ + disable_delayed_work(&dev->carrier_work); retval = ipheth_alloc_urbs(dev); if (retval) { dev_err(&intf->dev, "error allocating urbs: %d\n", retval); goto err_alloc_urbs; -- 2.43.0

2 1

[PATCH OLK-6.6] sctp: fix addr_wq_timer race in sctp_free_addr_wq()
by Zhang Qilong 08 Sep '26

08 Sep '26

From: Xin Long <lucien.xin(a)gmail.com> stable inclusion from stable-v6.18.40 commit a8323fb2ab6cd6978f359daeed6688e0cadf32ba category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17334 CVE: CVE-2026-72383 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 976c19de0f22a857ba0112f39635f8fd7a257568 ] sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete() while holding addr_wq_lock. However, timer_delete() does not guarantee that a currently running timer handler has completed. This allows a race with sctp_addr_wq_timeout_handler(), where the handler may still run after addr_waitq has been freed, acquire addr_wq_lock, and access freed memory, leading to a use-after-free. Fix this by calling timer_shutdown_sync() before taking addr_wq_lock. This guarantees that any in-flight timer handler has finished and prevents the timer from being re-armed during teardown, making subsequent cleanup safe. Fixes: 4db67e808640 ("sctp: Make the address lists per network namespace") Reported-by: Sashiko <sashiko-bot(a)kernel.org> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Link: https://patch.msgid.link/5dc95f295bdb5c3f60e880dd9aa5112dc5c071cc.178275787… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: net/sctp/protocol.c [Just context conflicts] Signed-off-by: Zhang Qilong <zhangqilong3(a)huawei.com> --- net/sctp/protocol.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c index 0beb9a82c2a3..a862644a6caa 100644 --- a/net/sctp/protocol.c +++ b/net/sctp/protocol.c @@ -690,12 +690,13 @@ static void sctp_addr_wq_timeout_handler(struct timer_list *t) static void sctp_free_addr_wq(struct net *net) { struct sctp_sockaddr_entry *addrw; struct sctp_sockaddr_entry *temp; + timer_shutdown_sync(&net->sctp.addr_wq_timer); + spin_lock_bh(&net->sctp.addr_wq_lock); - del_timer(&net->sctp.addr_wq_timer); list_for_each_entry_safe(addrw, temp, &net->sctp.addr_waitq, list) { list_del(&addrw->list); kfree(addrw); } spin_unlock_bh(&net->sctp.addr_wq_lock); -- 2.43.0

2 1

[PATCH OLK-6.6 0/3] md/raid1,raid10: fix deadlock and bio accounting in read error path
by Zhou Minqiang 08 Sep '26

08 Sep '26

Splitting a bio while executing in the raid1 thread can lead to recursion, as task->bio_list is NULL in this context. In addition, resubmitting an md_cloned_bio after splitting may lead to a deadlock if the array is suspended before the md driver calls percpu_ref_tryget_live(&mddev->active_io) on it's path to pers->make_request(). Avoid splitting the bio in this context and require that it is either read in full or not at all. This prevents recursion and avoids potential deadlocks during array suspension. Zhou Minqiang (3): md/raid1,raid10: fix deadlock in read error recovery path md/raid1,raid10: fix error-path detection with md_cloned_bio() md/raid1,raid10: fix bio accounting for split md cloned bios drivers/md/md.c | 40 ++++++++++++++++++++++++---------------- drivers/md/md.h | 5 +++++ drivers/md/raid1.c | 15 +++++++++++---- drivers/md/raid10.c | 28 ++++++++++++++++++---------- 4 files changed, 58 insertions(+), 30 deletions(-) -- 2.52.0

2 4

[PATCH OLK-6.6] enic: fix tx_hang_reset use-after-free on device removal
by Jinjiang Tu 08 Sep '26

08 Sep '26

From: Satish Kharat <satishkh(a)cisco.com> stable inclusion from stable-v6.12.104 commit 8619865f34fb3b130b567855382a5c4aadd522b9 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18260 CVE: CVE-2026-74725 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ec680ea4ba1bca92a767fb7e7869758bfdd886e3 ] enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free. cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work. Fixes: 937317c7c109 ("enic: do hang reset only in case of tx timeout") Signed-off-by: Satish Kharat <satishkh(a)cisco.com> Link: https://patch.msgid.link/20260728062730.2394873-1-satishkh@cisco.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/net/ethernet/cisco/enic/enic_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c index 48701032c20c..11cf6709b7c4 100644 --- a/drivers/net/ethernet/cisco/enic/enic_main.c +++ b/drivers/net/ethernet/cisco/enic/enic_main.c @@ -3016,8 +3016,9 @@ static void enic_remove(struct pci_dev *pdev) if (netdev) { struct enic *enic = netdev_priv(netdev); - cancel_work_sync(&enic->reset); - cancel_work_sync(&enic->change_mtu_work); + disable_work_sync(&enic->reset); + disable_work_sync(&enic->tx_hang_reset); + disable_work_sync(&enic->change_mtu_work); unregister_netdev(netdev); enic_dev_deinit(enic); vnic_dev_close(enic->vdev); -- 2.43.0

2 1