- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] net: pktgen: fix proc entry use-after-free
by JiangJieHua 31 Aug '26

31 Aug '26

From: Chengfeng Ye <nicoyip.dev(a)gmail.com> stable inclusion from stable-v6.6.153 commit 577443530cb592d5782a1f79847411a9363a65c8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17690 CVE: CVE-2026-74479 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 817ff6efdb7f484ea547218e11e17d8e43daa3b4 ] pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list. Fixes: 39df232f1a9b ("[PKTGEN]: fix device name handling") Cc: stable(a)vger.kernel.org Signed-off-by: Chengfeng Ye <nicoyip.dev(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20260719145740.2888967-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: net/core/pktgen.c [577443530cb5 moves proc_remove() into the if_lock-protected _rem_dev_from_if_list() helper to close a proc entry use-after-free race between pktgen_change_name() and pktgen_remove_device(). In the downstream tree the comment above pktgen_remove_device()'s proc_remove() call still used the single-line '*/' closing style, so the hunk was adjusted to drop the now-redundant proc_remove(pkt_dev->entry) call and the 'And update the thread if_list' comment, while keeping the proc_remove() addition inside _rem_dev_from_if_list() intact. Semantically equivalent to the upstream fix.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/core/pktgen.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/net/core/pktgen.c b/net/core/pktgen.c index 32a60c8195d5f..906cf7f8179af 100644 --- a/net/core/pktgen.c +++ b/net/core/pktgen.c @@ -3881,6 +3881,7 @@ static void _rem_dev_from_if_list(struct pktgen_thread *t, struct pktgen_dev *p; if_lock(t); + proc_remove(pkt_dev->entry); list_for_each_safe(q, n, &t->if_list) { p = list_entry(q, struct pktgen_dev, list); if (p == pkt_dev) @@ -3908,10 +3909,8 @@ static int pktgen_remove_device(struct pktgen_thread *t, /* Remove proc before if_list entry, because add_device uses * list to determine if interface already exist, avoid race - * with proc_create_data() */ - proc_remove(pkt_dev->entry); - - /* And update the thread if_list */ + * with proc_create_data() + */ _rem_dev_from_if_list(t, pkt_dev); #ifdef CONFIG_XFRM -- 2.33.8

2 1

[PATCH OLK-6.6] net: pktgen: fix proc entry use-after-free
by JiangJieHua 31 Aug '26

31 Aug '26

From: Chengfeng Ye <nicoyip.dev(a)gmail.com> stable inclusion from stable-v6.6.153 commit 577443530cb592d5782a1f79847411a9363a65c8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17690 CVE: CVE-2026-74479 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 817ff6efdb7f484ea547218e11e17d8e43daa3b4 ] pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list. Fixes: 39df232f1a9b ("[PKTGEN]: fix device name handling") Cc: stable(a)vger.kernel.org Signed-off-by: Chengfeng Ye <nicoyip.dev(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20260719145740.2888967-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: net/core/pktgen.c [577443530cb5 moves proc_remove() into the if_lock-protected _rem_dev_from_if_list() helper to close a proc entry use-after-free race between pktgen_change_name() and pktgen_remove_device(). In the downstream tree the comment above pktgen_remove_device()'s proc_remove() call still used the single-line '*/' closing style, so the hunk was adjusted to drop the now-redundant proc_remove(pkt_dev->entry) call and the 'And update the thread if_list' comment, while keeping the proc_remove() addition inside _rem_dev_from_if_list() intact. Semantically equivalent to the upstream fix.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/core/pktgen.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/core/pktgen.c b/net/core/pktgen.c index 32a60c8195d5f..83efb7be323eb 100644 --- a/net/core/pktgen.c +++ b/net/core/pktgen.c @@ -3881,6 +3881,7 @@ static void _rem_dev_from_if_list(struct pktgen_thread *t, struct pktgen_dev *p; if_lock(t); + proc_remove(pkt_dev->entry); list_for_each_safe(q, n, &t->if_list) { p = list_entry(q, struct pktgen_dev, list); if (p == pkt_dev) @@ -3909,9 +3910,6 @@ static int pktgen_remove_device(struct pktgen_thread *t, /* Remove proc before if_list entry, because add_device uses * list to determine if interface already exist, avoid race * with proc_create_data() */ - proc_remove(pkt_dev->entry); - - /* And update the thread if_list */ _rem_dev_from_if_list(t, pkt_dev); #ifdef CONFIG_XFRM -- 2.33.8

2 1

[PATCH OLK-6.6] tcp: challenge ACK for non-exact RST in SYN-RECEIVED
by JiangJieHua 31 Aug '26

31 Aug '26

From: Yuxiang Yang <yangyx22(a)mails.tsinghua.edu.cn> stable inclusion from stable-v6.6.153 commit 8b0a3a094f4cae2fb92e4d08d4eef7246a9d9c49 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16927 CVE: CVE-2026-68118 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a28c4fcbf774e23b4779cae468e3497a5ad1f4a1 ] The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response. Reported-by: Yuxiang Yang <yangyx22(a)mails.tsinghua.edu.cn> Reported-by: Yizhou Zhao <zhaoyz24(a)mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao(a)seu.edu.cn> Reported-by: Xuewei Feng <fengxw06(a)126.com> Reported-by: Qi Li <qli01(a)tsinghua.edu.cn> Reported-by: Ke Xu <xuke(a)tsinghua.edu.cn> Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2") Cc: stable(a)vger.kernel.org Signed-off-by: Yuxiang Yang <yangyx22(a)mails.tsinghua.edu.cn> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20260717081443.809393-2-yangyx22@mails.tsinghua.ed… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: include/net/tcp.h Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- include/net/tcp.h | 2 ++ net/ipv4/tcp_input.c | 56 ++++++++++++++++++++++++++++++---------- net/ipv4/tcp_minisocks.c | 12 ++++++++- 3 files changed, 56 insertions(+), 14 deletions(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 8674996bd39c6..a40864c5f2803 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -1685,6 +1685,8 @@ static inline bool tcp_paws_reject(const struct tcp_options_received *rx_opt, bool tcp_oow_rate_limited(struct net *net, const struct sk_buff *skb, int mib_idx, u32 *last_oow_ack_time); +void tcp_reqsk_send_challenge_ack(struct sock *sk, struct sk_buff *skb, + struct request_sock *req); static inline void tcp_mib_init(struct net *net) { diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index e6499904caf56..6af54c18f55ca 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -3744,24 +3744,17 @@ bool tcp_oow_rate_limited(struct net *net, const struct sk_buff *skb, return __tcp_oow_rate_limited(net, mib_idx, last_oow_ack_time); } -/* RFC 5961 7 [ACK Throttling] */ -static void tcp_send_challenge_ack(struct sock *sk) +/* Consume one slot from the per-netns RFC 5961 challenge ACK quota. + * Returns true if a challenge ACK may be sent. + */ +static bool tcp_challenge_ack_allowed(struct net *net) { - struct tcp_sock *tp = tcp_sk(sk); - struct net *net = sock_net(sk); u32 count, now, ack_limit; - /* First check our per-socket dupack rate limit. */ - if (__tcp_oow_rate_limited(net, - LINUX_MIB_TCPACKSKIPPEDCHALLENGE, - &tp->last_oow_ack_time)) - return; - ack_limit = READ_ONCE(net->ipv4.sysctl_tcp_challenge_ack_limit); if (ack_limit == INT_MAX) - goto send_ack; + return true; - /* Then check host-wide RFC 5961 rate limit. */ now = jiffies / HZ; if (now != READ_ONCE(net->ipv4.tcp_challenge_timestamp)) { u32 half = (ack_limit + 1) >> 1; @@ -3773,12 +3766,49 @@ static void tcp_send_challenge_ack(struct sock *sk) count = READ_ONCE(net->ipv4.tcp_challenge_count); if (count > 0) { WRITE_ONCE(net->ipv4.tcp_challenge_count, count - 1); -send_ack: + return true; + } + return false; +} + +/* RFC 5961 7 [ACK Throttling] */ +static void tcp_send_challenge_ack(struct sock *sk) +{ + struct tcp_sock *tp = tcp_sk(sk); + struct net *net = sock_net(sk); + + /* First check our per-socket dupack rate limit. */ + if (__tcp_oow_rate_limited(net, + LINUX_MIB_TCPACKSKIPPEDCHALLENGE, + &tp->last_oow_ack_time)) + return; + + /* Then check the per-netns RFC 5961 rate limit. */ + if (tcp_challenge_ack_allowed(net)) { NET_INC_STATS(net, LINUX_MIB_TCPCHALLENGEACK); tcp_send_ack(sk); } } +/* Send a challenge ACK from a SYN-RECEIVED request socket. Uses + * __tcp_oow_rate_limited() directly so that an RST carrying payload + * cannot bypass the per-request rate limit. + */ +void tcp_reqsk_send_challenge_ack(struct sock *sk, struct sk_buff *skb, + struct request_sock *req) +{ + struct net *net = sock_net(sk); + + if (__tcp_oow_rate_limited(net, LINUX_MIB_TCPACKSKIPPEDCHALLENGE, + &tcp_rsk(req)->last_oow_ack_time)) + return; + + if (tcp_challenge_ack_allowed(net)) { + NET_INC_STATS(net, LINUX_MIB_TCPCHALLENGEACK); + req->rsk_ops->send_ack(sk, skb, req); + } +} + static void tcp_store_ts_recent(struct tcp_sock *tp) { tp->rx_opt.ts_recent = tp->rx_opt.rcv_tsval; diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c index 8099563937e38..6138f546e90df 100644 --- a/net/ipv4/tcp_minisocks.c +++ b/net/ipv4/tcp_minisocks.c @@ -763,7 +763,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb, * elsewhere and is checked directly against the child socket rather * than req because user data may have been sent out. */ - if ((flg & TCP_FLAG_ACK) && !fastopen && + if ((flg & TCP_FLAG_ACK) && !(flg & TCP_FLAG_RST) && !fastopen && (TCP_SKB_CB(skb)->ack_seq != tcp_rsk(req)->snt_isn + 1)) return sk; @@ -802,6 +802,16 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb, flg &= ~TCP_FLAG_SYN; } + /* RFC 5961 section 3.2, as clarified by RFC 9293 section + * 3.10.7.4, requires a challenge ACK for a non-exact + * in-window RST in SYN-RECEIVED. + */ + if ((flg & TCP_FLAG_RST) && + TCP_SKB_CB(skb)->seq != tcp_rsk(req)->rcv_nxt) { + tcp_reqsk_send_challenge_ack(sk, skb, req); + return NULL; + } + /* RFC793: "second check the RST bit" and * "fourth, check the SYN bit" */ -- 2.33.8

2 1

[PATCH OLK-6.6 0/3] net: fix hard_header_len races in packet send paths Qihang
by JiangJieHua 31 Aug '26

31 Aug '26

Qihang Tang (3): net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header packet: use consistent hard_header_len in non-ring send paths packet: use consistent hard_header_len in TX_RING send path include/linux/netdevice.h | 11 ++++------ net/packet/af_packet.c | 45 +++++++++++++++++++++++---------------- 2 files changed, 31 insertions(+), 25 deletions(-) -- 2.33.8

2 4

[PATCH OLK-6.6 0/3] net: fix hard_header_len races in packet send paths
by JiangJieHua 31 Aug '26

31 Aug '26

Qihang Tang (3): net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header packet: use consistent hard_header_len in non-ring send paths packet: use consistent hard_header_len in TX_RING send path include/linux/netdevice.h | 11 ++++------ net/packet/af_packet.c | 45 +++++++++++++++++++++++---------------- 2 files changed, 31 insertions(+), 25 deletions(-) -- 2.33.8

2 4

[PATCH OLK-6.6] net: pktgen: fix proc entry use-after-free
by JiangJieHua 31 Aug '26

31 Aug '26

From: Chengfeng Ye <nicoyip.dev(a)gmail.com> stable inclusion from stable-v6.6.153 commit 577443530cb592d5782a1f79847411a9363a65c8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17690 CVE: CVE-2026-74479 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 817ff6efdb7f484ea547218e11e17d8e43daa3b4 ] pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list. Fixes: 39df232f1a9b ("[PKTGEN]: fix device name handling") Cc: stable(a)vger.kernel.org Signed-off-by: Chengfeng Ye <nicoyip.dev(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20260719145740.2888967-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: net/core/pktgen.c [577443530cb5 moves proc_remove() into the if_lock-protected _rem_dev_from_if_list() helper to close a proc entry use-after-free race between pktgen_change_name() and pktgen_remove_device(). In the downstream tree the comment above pktgen_remove_device()'s proc_remove() call still used the single-line '*/' closing style, so the hunk was adjusted to drop the now-redundant proc_remove(pkt_dev->entry) call and the 'And update the thread if_list' comment, while keeping the proc_remove() addition inside _rem_dev_from_if_list() intact. Semantically equivalent to the upstream fix.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/core/pktgen.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/core/pktgen.c b/net/core/pktgen.c index 32a60c8195d5f..83efb7be323eb 100644 --- a/net/core/pktgen.c +++ b/net/core/pktgen.c @@ -3881,6 +3881,7 @@ static void _rem_dev_from_if_list(struct pktgen_thread *t, struct pktgen_dev *p; if_lock(t); + proc_remove(pkt_dev->entry); list_for_each_safe(q, n, &t->if_list) { p = list_entry(q, struct pktgen_dev, list); if (p == pkt_dev) @@ -3909,9 +3910,6 @@ static int pktgen_remove_device(struct pktgen_thread *t, /* Remove proc before if_list entry, because add_device uses * list to determine if interface already exist, avoid race * with proc_create_data() */ - proc_remove(pkt_dev->entry); - - /* And update the thread if_list */ _rem_dev_from_if_list(t, pkt_dev); #ifdef CONFIG_XFRM -- 2.33.8

2 1

[PATCH OLK-5.10] nvme-multipath: fix flex array size in struct nvme_ns_head
by Zhou Minqiang 31 Aug '26

31 Aug '26

mainline inclusion from mainline-v7.2-rc1 commit 001e57554de81aa79c25c18fd53911d8a415c304 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18145 CVE: CVE-2026-74384 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs. Fixes: f333444708f8 ("nvme: take node locality into account when selecting a path") Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> Reviewed-by: Hannes Reinecke <hare(a)kernel.org> Reviewed-by: John Garry <john.g.garry(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Nilay Shroff <nilay(a)linux.ibm.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Zhou Minqiang <zhouminqiang2(a)huawei.com> --- drivers/nvme/host/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 7d1bfac3f998..cd2858916b64 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -3817,7 +3817,7 @@ static struct nvme_ns_head *nvme_alloc_ns_head(struct nvme_ctrl *ctrl, int ret = -ENOMEM; #ifdef CONFIG_NVME_MULTIPATH - size += num_possible_nodes() * sizeof(struct nvme_ns *); + size += nr_node_ids * sizeof(struct nvme_ns *); #endif head = kzalloc(size, GFP_KERNEL); -- 2.52.0

2 1

[PATCH OLK-6.6 0/2] CVE-2026-68095
by Zhou Minqiang 31 Aug '26

31 Aug '26

CVE-2026-68095 Zhou Minqiang (2): fuse-uring: fix race between registration and connection abortion fuse-uring: check connection abort during ring creation fs/fuse/dev_uring.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6] iomap: fix out-of-bounds bitmap_set() with zero-length range
by Zhou Minqiang 31 Aug '26

31 Aug '26

mainline inclusion from mainline-v7.2-rc5 commit 9c7d8f7c8994c790fca501dc45ce66e7356cbe05 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16953 CVE: CVE-2026-68145 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op. Fixes: 4ce02c679722 ("iomap: Add per-block dirty state tracking to improve performance") Cc: stable(a)vger.kernel.org # v6.6 Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Link: https://patch.msgid.link/20260714082325.325163-5-yi.zhang@huaweicloud.com Reviewed-by: Joanne Koong <joannelkoong(a)gmail.com> Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Christian Brauner (Amutable) <brauner(a)kernel.org> Signed-off-by: Zhou Minqiang <zhouminqiang2(a)huawei.com> --- fs/iomap/buffered-io.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 172d4db55301..1b9177ad7cdd 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -61,13 +61,15 @@ static void ifs_set_range_uptodate(struct folio *folio, struct iomap_folio_state *ifs, size_t off, size_t len) { struct inode *inode = folio->mapping->host; - unsigned int first_blk = off >> inode->i_blkbits; - unsigned int last_blk = (off + len - 1) >> inode->i_blkbits; - unsigned int nr_blks = last_blk - first_blk + 1; + unsigned int first_blk, last_blk; unsigned long flags; spin_lock_irqsave(&ifs->state_lock, flags); - bitmap_set(ifs->state, first_blk, nr_blks); + if (len) { + first_blk = off >> inode->i_blkbits; + last_blk = (off + len - 1) >> inode->i_blkbits; + bitmap_set(ifs->state, first_blk, last_blk - first_blk + 1); + } if (ifs_is_fully_uptodate(folio, ifs)) folio_mark_uptodate(folio); spin_unlock_irqrestore(&ifs->state_lock, flags); @@ -163,13 +165,17 @@ static void ifs_set_range_dirty(struct folio *folio, { struct inode *inode = folio->mapping->host; unsigned int blks_per_folio = i_blocks_per_folio(inode, folio); - unsigned int first_blk = (off >> inode->i_blkbits); - unsigned int last_blk = (off + len - 1) >> inode->i_blkbits; - unsigned int nr_blks = last_blk - first_blk + 1; + unsigned int first_blk, last_blk; unsigned long flags; + if (!len) + return; + + first_blk = off >> inode->i_blkbits; + last_blk = (off + len - 1) >> inode->i_blkbits; spin_lock_irqsave(&ifs->state_lock, flags); - bitmap_set(ifs->state, first_blk + blks_per_folio, nr_blks); + bitmap_set(ifs->state, first_blk + blks_per_folio, + last_blk - first_blk + 1); spin_unlock_irqrestore(&ifs->state_lock, flags); } -- 2.52.0

2 1

[PATCH OLK-5.10 0/2] mainline patch submission for OLK-5.10
by Chen Yuxi 31 Aug '26

31 Aug '26

Jiri Olsa (1): bpf: Clear buf on error in __bpf_get_task_stack Kumar Kartikeya Dwivedi (1): bpf: Zero queue and stack outputs on lock failure kernel/bpf/queue_stack_maps.c | 8 ++++++-- kernel/bpf/stackmap.c | 7 +++++-- 2 files changed, 11 insertions(+), 4 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] bpf: Simplify sanitize_err() signature
by Pu Lehui 31 Aug '26

31 Aug '26

From: Eduard Zingerman <eddyz87(a)gmail.com> mainline inclusion from mainline-v7.2-rc7 commit a15970d916b39acc7c60a0a99c27a6e378690aa9 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18233 CVE: CVE-2026-74720 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The sanitize_err() function is called when: - ptr += scalar - scalar += ptr - scalar += scalar ALU operations are processed. This commit drops offset and pointer registers parameters from its signature to simplify the follow-up changes for 'scalar += ptr' case. regs[src].type is safe to access, as it is not mutated by the callers. Signed-off-by: Yiyang Chen <chenyy23(a)mails.tsinghua.edu.cn> Acked-by: Shung-Hsi Yu <shung-hsi.yu(a)suse.com> Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-1-8ee297e2346b@ma… Signed-off-by: Eduard Zingerman <eddyz87(a)gmail.com> Conflicts: kernel/bpf/verifier.c [ctx conflicts] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 71cc52cfaf31..1c66b6df3cdb 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2961,23 +2961,21 @@ static void sanitize_mark_insn_seen(struct bpf_verifier_env *env) env->insn_aux_data[env->insn_idx].seen = true; } -static int sanitize_err(struct bpf_verifier_env *env, - const struct bpf_insn *insn, int reason, - const struct bpf_reg_state *off_reg, - const struct bpf_reg_state *dst_reg) +static int sanitize_err(struct bpf_verifier_env *env, const struct bpf_insn *insn, int reason) { static const char *err = "pointer arithmetic with it prohibited for !root"; const char *op = BPF_OP(insn->code) == BPF_ADD ? "add" : "sub"; u32 dst = insn->dst_reg, src = insn->src_reg; + struct bpf_reg_state *regs = cur_regs(env); switch (reason) { case REASON_BOUNDS: verbose(env, "R%d has unknown scalar with mixed signed bounds, %s\n", - off_reg == dst_reg ? dst : src, err); + regs[src].type == SCALAR_VALUE ? src : dst, err); break; case REASON_TYPE: verbose(env, "R%d has pointer with unsupported alu operation, %s\n", - off_reg == dst_reg ? src : dst, err); + regs[src].type == SCALAR_VALUE ? dst : src, err); break; case REASON_PATHS: verbose(env, "R%d tried to %s from different maps, paths or scalars, %s\n", @@ -3139,7 +3137,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, ret = sanitize_ptr_alu(env, insn, ptr_reg, off_reg, dst_reg, &info, false); if (ret < 0) - return sanitize_err(env, insn, ret, off_reg, dst_reg); + return sanitize_err(env, insn, ret); } switch (opcode) { @@ -3281,7 +3279,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, ret = sanitize_ptr_alu(env, insn, dst_reg, off_reg, dst_reg, &info, true); if (ret < 0) - return sanitize_err(env, insn, ret, off_reg, dst_reg); + return sanitize_err(env, insn, ret); } return 0; @@ -3338,7 +3336,7 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env, if (sanitize_needed(opcode)) { ret = sanitize_val_alu(env, insn); if (ret < 0) - return sanitize_err(env, insn, ret, NULL, NULL); + return sanitize_err(env, insn, ret); } switch (opcode) { -- 2.34.1

2 1

[PATCH OLK-6.6 0/5] backport cpufreq patches from linux mainline on August 31st
by Pengjie Zhang 31 Aug '26

31 Aug '26

From: Hongye Lin <linhongye(a)h-partners.com> driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9163 -------------------------------- backport cpufreq patches from linux mainline on August 31st Jie Zhan (1): cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged Pengjie Zhang (4): Revert "cpufreq: CPPC: Keep the target core awake when reading its cpufreq rate" ACPI: CPPC: add paired FFH feedback-counter read hook arm64: topology: read CPPC FFH feedback counters in one operation cpufreq: CPPC: Optimize feedback counter sampling based on BIOS FFH capability arch/arm64/kernel/topology.c | 92 +++++++++++++++++++++++++++--- drivers/acpi/cppc_acpi.c | 85 ++++++++++++++++++++++----- drivers/cpufreq/cppc_cpufreq.c | 101 +++++++++++++++++++++++++++------ include/acpi/cppc_acpi.h | 12 ++++ 4 files changed, 253 insertions(+), 37 deletions(-) -- 2.33.0

2 6

[PATCH OLK-5.10] dmaengine: Fix possible use after free
by Fanhua Li 31 Aug '26

31 Aug '26

From: Nuno Sá <nuno.sa(a)analog.com> stable inclusion from stable-v5.10.261 commit 444f96066937f3fdf0e79b53289cff223c7d638b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17591 CVE: CVE-2026-72476 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 92f853f0645aebf1d05d333e97ab7c342ace1892 ] In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check. Fixes: 0f571515c332 ("dmaengine: Add privatecnt to revert DMA_PRIVATE property") Signed-off-by: Nuno Sá <nuno.sa(a)analog.com> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Link: https://patch.msgid.link/20260424-dma-dmac-handle-vunmap-v4-1-90f43412fdc0@… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/dma/dmaengine.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index 9559ebd61f3bb..68078e83d5756 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -906,11 +906,12 @@ void dma_release_channel(struct dma_chan *chan) mutex_lock(&dma_list_mutex); WARN_ONCE(chan->client_count != 1, "chan reference count %d != 1\n", chan->client_count); - dma_chan_put(chan); /* drop PRIVATE cap enabled by __dma_request_channel() */ if (--chan->device->privatecnt == 0) dma_cap_clear(DMA_PRIVATE, chan->device->cap_mask); + dma_chan_put(chan); + if (chan->slave) { sysfs_remove_link(&chan->dev->device.kobj, DMA_SLAVE_NAME); sysfs_remove_link(&chan->slave->kobj, chan->name); -- 2.43.0

2 1

[PATCH OLK-5.10] vhost/vdpa: validate virtqueue index in mmap and fault paths
by Fanhua Li 31 Aug '26

31 Aug '26

From: Qihang Tang <q.h.hack.winter(a)gmail.com> stable inclusion from stable-v5.10.261 commit 0f310bac6db9bd3bb1655707d692d9d2a86eeb17 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18146 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 929e4f044621c8cc30b612fb74e1410bef09e41b ] vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS. Fixes: ddd89d0a059d ("vhost_vdpa: support doorbell mapping via mmap") Acked-by: Eugenio Pérez <eperezma(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Qihang Tang <q.h.hack.winter(a)gmail.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Message-ID: <20260508075821.92656-1-q.h.hack.winter(a)gmail.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/vhost/vdpa.c | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index 88c9d7665cedb..56d99c3d0a389 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -1567,16 +1567,32 @@ static int vhost_vdpa_release(struct inode *inode, struct file *filep) } #ifdef CONFIG_MMU -static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf) +static int +vhost_vdpa_get_vq_notification(struct vhost_vdpa *v, unsigned long index, + struct vdpa_notification_area *notify) { - struct vhost_vdpa *v = vmf->vma->vm_file->private_data; struct vdpa_device *vdpa = v->vdpa; const struct vdpa_config_ops *ops = vdpa->config; + + if (index > 65535 || index >= v->nvqs) + return -EINVAL; + + index = array_index_nospec(index, v->nvqs); + + *notify = ops->get_vq_notification(vdpa, index); + + return 0; +} + +static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf) +{ + struct vhost_vdpa *v = vmf->vma->vm_file->private_data; struct vdpa_notification_area notify; struct vm_area_struct *vma = vmf->vma; - u16 index = vma->vm_pgoff; + unsigned long index = vma->vm_pgoff; - notify = ops->get_vq_notification(vdpa, index); + if (vhost_vdpa_get_vq_notification(v, index, &notify)) + return VM_FAULT_SIGBUS; vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); if (remap_pfn_range(vma, vmf->address & PAGE_MASK, @@ -1605,8 +1621,6 @@ static int vhost_vdpa_mmap(struct file *file, struct vm_area_struct *vma) return -EINVAL; if (vma->vm_flags & VM_READ) return -EINVAL; - if (index > 65535) - return -EINVAL; if (!ops->get_vq_notification) return -ENOTSUPP; @@ -1614,7 +1628,8 @@ static int vhost_vdpa_mmap(struct file *file, struct vm_area_struct *vma) * support the doorbell which sits on the page boundary and * does not share the page with other registers. */ - notify = ops->get_vq_notification(vdpa, index); + if (vhost_vdpa_get_vq_notification(v, index, &notify)) + return -EINVAL; if (notify.addr & (PAGE_SIZE - 1)) return -EINVAL; if (vma->vm_end - vma->vm_start != notify.size) -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] dmaengine: Fix possible use after free
by Fanhua Li 31 Aug '26

31 Aug '26

From: Nuno Sá <nuno.sa(a)analog.com> stable inclusion from stable-v5.10.261 commit 444f96066937f3fdf0e79b53289cff223c7d638b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17591 CVE: CVE-2026-72476 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 92f853f0645aebf1d05d333e97ab7c342ace1892 ] In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check. Fixes: 0f571515c332 ("dmaengine: Add privatecnt to revert DMA_PRIVATE property") Signed-off-by: Nuno Sá <nuno.sa(a)analog.com> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Link: https://patch.msgid.link/20260424-dma-dmac-handle-vunmap-v4-1-90f43412fdc0@… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/dma/dmaengine.c [Fanhua Li: context conflict] Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/dma/dmaengine.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index 450b1c4b21294..b4bb44f295d17 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -787,10 +787,11 @@ void dma_release_channel(struct dma_chan *chan) mutex_lock(&dma_list_mutex); WARN_ONCE(chan->client_count != 1, "chan reference count %d != 1\n", chan->client_count); - dma_chan_put(chan); /* drop PRIVATE cap enabled by __dma_request_channel() */ if (--chan->device->privatecnt == 0) dma_cap_clear(DMA_PRIVATE, chan->device->cap_mask); + + dma_chan_put(chan); mutex_unlock(&dma_list_mutex); } EXPORT_SYMBOL_GPL(dma_release_channel); -- 2.43.0

2 1

[PATCH OLK-6.6 0/4] mainline patch submission for OLK-6.6
by Chen Yuxi 31 Aug '26

31 Aug '26

Jiri Olsa (1): bpf: Clear buf on error in __bpf_get_task_stack Junseo Lim (1): bpf: Reject negative optlen in cgroup getsockopt hook Kumar Kartikeya Dwivedi (1): bpf: Zero queue and stack outputs on lock failure Leon Hwang (1): bpf: Fix WARNING in bpf_tracing_link_release include/linux/bpf.h | 3 +++ kernel/bpf/cgroup.c | 2 +- kernel/bpf/queue_stack_maps.c | 8 ++++++-- kernel/bpf/stackmap.c | 7 +++++-- kernel/bpf/trampoline.c | 7 +++++++ kernel/bpf/verifier.c | 2 +- 6 files changed, 23 insertions(+), 6 deletions(-) -- 2.34.1

2 5

[PATCH OLK-6.6 v4 0/7] CVE-2026-74314
by Pu Lehui 31 Aug '26

31 Aug '26

Benjamin Tissoires (1): bpf: Do not walk twice the hash map on free Hou Tao (1): bpf: Factor out htab_elem_value helper() Justin Suess (1): bpf: Cancel special fields on map value recycle Kumar Kartikeya Dwivedi (1): bpf: Register dtor for freeing special fields Mykyta Yatsenko (2): bpf: htab: extract helper for freeing special structs bpf: Extract internal structs validation logic into helpers Pu Lehui (1): bpf: Fix kabi breakage for struct bpf_mem_alloc include/linux/bpf.h | 8 + include/linux/bpf_mem_alloc.h | 4 + kernel/bpf/arraymap.c | 12 +- kernel/bpf/hashtab.c | 198 +++++++++++++----- kernel/bpf/helpers.c | 6 + kernel/bpf/memalloc.c | 74 ++++++- kernel/bpf/syscall.c | 5 + .../selftests/bpf/prog_tests/linked_list.c | 33 +-- .../selftests/bpf/prog_tests/map_kptr.c | 10 +- .../testing/selftests/bpf/progs/linked_list.c | 51 +++++ 10 files changed, 306 insertions(+), 95 deletions(-) -- 2.34.1

2 8

[PATCH OLK-5.10 0/2] mainline patch submission for OLK-5.10
by Chen Yuxi 31 Aug '26

31 Aug '26

Jiri Olsa (1): bpf: Clear buf on error in __bpf_get_task_stack Kumar Kartikeya Dwivedi (1): bpf: Zero queue and stack outputs on lock failure kernel/bpf/queue_stack_maps.c | 8 ++++++-- kernel/bpf/stackmap.c | 6 +++++- 2 files changed, 11 insertions(+), 3 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] iommu/amd: Bound the early ACPI HID map
by Zhang Yuwei 31 Aug '26

31 Aug '26

From: Pengpeng Hou <pengpeng(a)iscas.ac.cn> stable inclusion from stable-v6.6.148 commit 1e31d2394e0db69541b1591d46c5ad6431c81db3 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18558 CVE: CVE-2026-68325 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fb80117fddb5b477218dc99bb53911b72c3847f8 ] The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> Reviewed-by: Ankit Soni <Ankit.Soni(a)amd.com> Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Conflicts: drivers/iommu/amd_iommu_init.c drivers/iommu/amd/init.c [context conflict] Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> --- drivers/iommu/amd_iommu_init.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 9903fd400eb2..3aba73aa2cb7 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -2955,6 +2955,12 @@ static int __init parse_ivrs_acpihid(char *str) return 1; } + if (early_acpihid_map_size == EARLY_MAP_SIZE) { + pr_err("AMD-Vi: Early ACPI HID map overflow - ignoring ivrs_acpihid%s\n", + str); + return 1; + } + p = acpiid; hid = strsep(&p, ":"); uid = p; -- 2.22.0

2 1

[PATCH OLK-5.10] iommu/amd: Bound the early ACPI HID map
by Zhang Yuwei 31 Aug '26

31 Aug '26

From: Pengpeng Hou <pengpeng(a)iscas.ac.cn> stable inclusion from stable-v5.10.265 commit 9ae6b1b972ce01d3316c8a5f7f58c8b3668cc6bb category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17151 CVE: CVE-2026-68325 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fb80117fddb5b477218dc99bb53911b72c3847f8 ] The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> Reviewed-by: Ankit Soni <Ankit.Soni(a)amd.com> Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> --- drivers/iommu/amd/init.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index d8ca624a2e12..bf47e84e070b 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -3264,6 +3264,12 @@ static int __init parse_ivrs_acpihid(char *str) return 1; found: + if (early_acpihid_map_size == EARLY_MAP_SIZE) { + pr_err("Early ACPI HID map overflow - ignoring ivrs_acpihid%s\n", + str); + return 1; + } + p = acpiid; hid = strsep(&p, ":"); uid = p; -- 2.22.0

2 1

[Patch OLK-5.10 0/2] mainline patch submission for OLK-5.10
by Chen Yuxi 31 Aug '26

31 Aug '26

Jiri Olsa (1): bpf: Clear buf on error in __bpf_get_task_stack Kumar Kartikeya Dwivedi (1): bpf: Zero queue and stack outputs on lock failure kernel/bpf/queue_stack_maps.c | 8 ++++++-- kernel/bpf/stackmap.c | 6 +++++- 2 files changed, 11 insertions(+), 3 deletions(-) -- 2.34.1

1 2

[PATCH OLK-6.6] vhost_iotlb: bound map allocation in add_range
by Lin Ruifeng 31 Aug '26

31 Aug '26

From: Linfeng Sun <linfeng.sun.dev(a)gamil.com> stable inclusion from stable-v7.1.9 commit ae128dd19040ee06a4f8143c7ced4d18080d7a9a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18250 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1ed35ac7f3fe2b4396bdd29ac3a7f0ebc0829e94 ] vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit. Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error. Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries. Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind. When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL. I found this bug myself, though the patch was written with AI assistance. Fixes: 0bbe30668d89 ("vhost: factor out IOTLB") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun <linfeng.sun.dev(a)gamil.com> Message-ID: <AMYAtgAiKmgYcSQT5ukl-4qq.3.1781960405943.Hmail.241270009(a)hdu.edu.cn> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/vdpa/mlx5/core/mr.c drivers/vdpa/vdpa_sim/vdpa_sim.c drivers/vdpa/vdpa_user/iova_domain.c drivers/vhost/iotlb.c drivers/vhost/vdpa.c drivers/vhost/vhost.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/vdpa/mlx5/core/mlx5_vdpa.h | 2 ++ drivers/vdpa/mlx5/core/mr.c | 3 ++ drivers/vdpa/mlx5/core/resources.c | 11 ++++++- drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++- drivers/vdpa/vdpa_user/iova_domain.c | 11 ++++++- drivers/vhost/iotlb.c | 47 +++++++++++++++++++--------- drivers/vhost/vdpa.c | 9 +++++- drivers/vhost/vhost.c | 8 +++++ 8 files changed, 77 insertions(+), 18 deletions(-) diff --git a/drivers/vdpa/mlx5/core/mlx5_vdpa.h b/drivers/vdpa/mlx5/core/mlx5_vdpa.h index ca56242972b3..869219529ff1 100644 --- a/drivers/vdpa/mlx5/core/mlx5_vdpa.h +++ b/drivers/vdpa/mlx5/core/mlx5_vdpa.h @@ -11,6 +11,8 @@ #define MLX5V_ETH_HARD_MTU (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN) +extern int mlx5_vdpa_max_iotlb_entries; + struct mlx5_vdpa_direct_mr { u64 start; u64 end; diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c index 165730656934..b7c1d532ccbc 100644 --- a/drivers/vdpa/mlx5/core/mr.c +++ b/drivers/vdpa/mlx5/core/mr.c @@ -577,6 +577,9 @@ static int _mlx5_vdpa_create_mr(struct mlx5_vdpa_dev *mvdev, { int err; + if (mlx5_vdpa_max_iotlb_entries < 2) + return -EINVAL; + err = _mlx5_vdpa_create_dvq_mr(mvdev, iotlb, asid); if (err) return err; diff --git a/drivers/vdpa/mlx5/core/resources.c b/drivers/vdpa/mlx5/core/resources.c index d5a59c9035fb..00b66438ab53 100644 --- a/drivers/vdpa/mlx5/core/resources.c +++ b/drivers/vdpa/mlx5/core/resources.c @@ -3,8 +3,14 @@ #include <linux/iova.h> #include <linux/mlx5/driver.h> +#include <linux/moduleparam.h> #include "mlx5_vdpa.h" +int mlx5_vdpa_max_iotlb_entries = 2048; +module_param_named(max_iotlb_entries, mlx5_vdpa_max_iotlb_entries, int, 0444); +MODULE_PARM_DESC(max_iotlb_entries, + "Maximum number of iotlb entries. (default: 2048)"); + static int alloc_pd(struct mlx5_vdpa_dev *dev, u32 *pdn, u16 uid) { struct mlx5_core_dev *mdev = dev->mdev; @@ -229,7 +235,10 @@ int mlx5_vdpa_destroy_mkey(struct mlx5_vdpa_dev *mvdev, u32 mkey) static int init_ctrl_vq(struct mlx5_vdpa_dev *mvdev) { - mvdev->cvq.iotlb = vhost_iotlb_alloc(0, 0); + if (mlx5_vdpa_max_iotlb_entries < 2) + return -EINVAL; + + mvdev->cvq.iotlb = vhost_iotlb_alloc(mlx5_vdpa_max_iotlb_entries, 0); if (!mvdev->cvq.iotlb) return -ENOMEM; diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c index af59d90ba9a8..36b7c12e2a73 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c @@ -34,7 +34,7 @@ MODULE_PARM_DESC(batch_mapping, "Batched mapping 1 -Enable; 0 - Disable"); static int max_iotlb_entries = 2048; module_param(max_iotlb_entries, int, 0444); MODULE_PARM_DESC(max_iotlb_entries, - "Maximum number of iotlb entries for each address space. 0 means unlimited. (default: 2048)"); + "Maximum number of iotlb entries for each address space. (default: 2048)"); static bool use_va = true; module_param(use_va, bool, 0444); @@ -199,6 +199,8 @@ struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *dev_attr, if (!dev_attr->alloc_size) return ERR_PTR(-EINVAL); + if (max_iotlb_entries < 2) + return ERR_PTR(-EINVAL); if (config->mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES)) { if (config->device_features & diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c index cc8d26b97187..0a7791803132 100644 --- a/drivers/vdpa/vdpa_user/iova_domain.c +++ b/drivers/vdpa/vdpa_user/iova_domain.c @@ -12,11 +12,17 @@ #include <linux/file.h> #include <linux/anon_inodes.h> #include <linux/highmem.h> +#include <linux/moduleparam.h> #include <linux/vmalloc.h> #include <linux/vdpa.h> #include "iova_domain.h" +static int max_iotlb_entries = 2048; +module_param(max_iotlb_entries, int, 0444); +MODULE_PARM_DESC(max_iotlb_entries, + "Maximum number of iotlb entries. (default: 2048)"); + static int vduse_iotlb_add_range(struct vduse_iova_domain *domain, u64 start, u64 last, u64 addr, unsigned int perm, @@ -607,12 +613,15 @@ vduse_domain_create(unsigned long iova_limit, size_t bounce_size) bounce_pfns = PAGE_ALIGN(bounce_size) >> BOUNCE_MAP_SHIFT; if (iova_limit <= bounce_size) return NULL; + + if (max_iotlb_entries <= 0) + return NULL; domain = kzalloc(sizeof(*domain), GFP_KERNEL); if (!domain) return NULL; - domain->iotlb = vhost_iotlb_alloc(0, 0); + domain->iotlb = vhost_iotlb_alloc(max_iotlb_entries, 0); if (!domain->iotlb) goto err_iotlb; diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c index ea61330a3431..a6228dd24931 100644 --- a/drivers/vhost/iotlb.c +++ b/drivers/vhost/iotlb.c @@ -20,6 +20,14 @@ INTERVAL_TREE_DEFINE(struct vhost_iotlb_map, rb, __u64, __subtree_last, START, LAST, static inline, vhost_iotlb_itree); +static void vhost_iotlb_map_unlink(struct vhost_iotlb *iotlb, + struct vhost_iotlb_map *map) +{ + vhost_iotlb_itree_remove(map, &iotlb->root); + list_del(&map->link); + iotlb->nmaps--; +} + /** * vhost_iotlb_map_free - remove a map node and free it * @iotlb: the IOTLB @@ -28,10 +36,8 @@ INTERVAL_TREE_DEFINE(struct vhost_iotlb_map, void vhost_iotlb_map_free(struct vhost_iotlb *iotlb, struct vhost_iotlb_map *map) { - vhost_iotlb_itree_remove(map, &iotlb->root); - list_del(&map->link); + vhost_iotlb_map_unlink(iotlb, map); kfree(map); - iotlb->nmaps--; } EXPORT_SYMBOL_GPL(vhost_iotlb_map_free); @@ -57,14 +63,25 @@ int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb, if (last < start) return -EFAULT; + if (!iotlb->limit) + return -EINVAL; + /* If the range being mapped is [0, ULONG_MAX], split it into two entries * otherwise its size would overflow u64. */ if (start == 0 && last == ULONG_MAX) { u64 mid = last / 2; - int err = vhost_iotlb_add_range_ctx(iotlb, start, mid, addr, - perm, opaque); + int err; + + if (iotlb->limit < 2) + return -ENOSPC; + if (!(iotlb->flags & VHOST_IOTLB_FLAG_RETIRE) && + iotlb->nmaps > iotlb->limit - 2) + return -ENOSPC; + + err = vhost_iotlb_add_range_ctx(iotlb, start, mid, addr, + perm, opaque); if (err) return err; @@ -72,17 +89,19 @@ int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb, start = mid + 1; } - if (iotlb->limit && - iotlb->nmaps == iotlb->limit && - iotlb->flags & VHOST_IOTLB_FLAG_RETIRE) { - map = list_first_entry(&iotlb->list, typeof(*map), link); - vhost_iotlb_map_free(iotlb, map); + if (iotlb->nmaps >= iotlb->limit) { + if (iotlb->flags & VHOST_IOTLB_FLAG_RETIRE) { + map = list_first_entry(&iotlb->list, typeof(*map), link); + vhost_iotlb_map_unlink(iotlb, map); + } else { + return -ENOSPC; + } + } else { + map = kmalloc(sizeof(*map), GFP_ATOMIC); + if (!map) + return -ENOMEM; } - map = kmalloc(sizeof(*map), GFP_ATOMIC); - if (!map) - return -ENOMEM; - map->start = start; map->size = last - start + 1; map->last = last; diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index 0583374602f8..42a5fda693e8 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -37,6 +37,11 @@ enum { #define VHOST_VDPA_DEV_MAX (1U << MINORBITS) +static int max_iotlb_entries = 2048; +module_param(max_iotlb_entries, int, 0444); +MODULE_PARM_DESC(max_iotlb_entries, + "Maximum number of iotlb entries. (default: 2048)"); + #define VHOST_VDPA_IOTLB_BUCKETS 16 struct vhost_vdpa_as { @@ -114,12 +119,14 @@ static struct vhost_vdpa_as *vhost_vdpa_alloc_as(struct vhost_vdpa *v, u32 asid) if (asid >= v->vdpa->nas) return NULL; + if (max_iotlb_entries <= 0) + return NULL; as = kmalloc(sizeof(*as), GFP_KERNEL); if (!as) return NULL; - vhost_iotlb_init(&as->iotlb, 0, 0); + vhost_iotlb_init(&as->iotlb, max_iotlb_entries, 0); as->id = asid; hlist_add_head(&as->hash_link, head); diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index a58be2369fdc..2b410ddffac2 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -977,6 +977,9 @@ EXPORT_SYMBOL_GPL(vhost_dev_set_owner); static struct vhost_iotlb *iotlb_alloc(void) { + if (max_iotlb_entries <= 0) + return NULL; + return vhost_iotlb_alloc(max_iotlb_entries, VHOST_IOTLB_FLAG_RETIRE); } @@ -1817,6 +1820,8 @@ static long vhost_set_memory(struct vhost_dev *d, struct vhost_memory __user *m) return -EOPNOTSUPP; if (mem.nregions > max_mem_regions) return -E2BIG; + if (max_iotlb_entries <= 0) + return -EINVAL; newmem = kvzalloc(struct_size(newmem, regions, mem.nregions), GFP_KERNEL); if (!newmem) @@ -2111,6 +2116,9 @@ int vhost_init_device_iotlb(struct vhost_dev *d) struct vhost_iotlb *niotlb, *oiotlb; int i; + if (max_iotlb_entries <= 0) + return -EINVAL; + niotlb = iotlb_alloc(); if (!niotlb) return -ENOMEM; -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] CVE-2026-74730
by Zhou Minqiang 31 Aug '26

31 Aug '26

CVE-2026-74730 Zhou Minqiang (2): [Backport] NFS: Pin the 'struct nfs_server' during a FREE_STATEID call [Backport] NFS: Decrement refcounts if allocating nfs_free_stateid_data fails fs/nfs/nfs4proc.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6 0/2] CVE-2026-74730
by Zhou Minqiang 31 Aug '26

31 Aug '26

CVE-2026-74730 Zhou Minqiang (2): [Backport] NFS: Pin the 'struct nfs_server' during a FREE_STATEID call [Backport] NFS: Decrement refcounts if allocating nfs_free_stateid_data fails fs/nfs/nfs4proc.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6 0/4] [OLK-6.6] mainline patch submission
by Chen Yuxi 31 Aug '26

31 Aug '26

*** BLURB HERE *** Jiri Olsa (1): bpf: Clear buf on error in __bpf_get_task_stack Junseo Lim (1): bpf: Reject negative optlen in cgroup getsockopt hook Kumar Kartikeya Dwivedi (1): bpf: Zero queue and stack outputs on lock failure Leon Hwang (1): bpf: Fix WARNING in bpf_tracing_link_release include/linux/bpf.h | 3 +++ kernel/bpf/cgroup.c | 2 +- kernel/bpf/queue_stack_maps.c | 8 ++++++-- kernel/bpf/stackmap.c | 6 +++++- kernel/bpf/trampoline.c | 7 +++++++ kernel/bpf/verifier.c | 2 +- 6 files changed, 23 insertions(+), 5 deletions(-) -- 2.34.1

2 5

[PATCH OLK-6.6 0/2] Fix CVE-2026-74730
by Zhou Minqiang 29 Aug '26

29 Aug '26

Fix CVE-2026-74730 Zhou Minqiang (2): NFS: Pin the 'struct nfs_server' during a FREE_STATEID call NFS: Decrement refcounts if allocating nfs_free_stateid_data fails fs/nfs/nfs4proc.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) -- 2.52.0

2 3

[PATCH openEuler-1.0-LTS] vhost/net: complete zerocopy ubufs only once
by Jiacheng Yu 29 Aug '26

29 Aug '26

From: Qing Ming <a0yami(a)mailbox.org> mainline inclusion from mainline-v7.2-rc1 commit 8f6898fe80794f2d7c3d38c1158c806e4074a1c4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17657 CVE: CVE-2026-74310 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs. Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support") Signed-off-by: Qing Ming <a0yami(a)mailbox.org> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Message-ID: <20260601104300.197210-1-a0yami(a)mailbox.org> Conflicts: drivers/vhost/net.c [7ab4f16f9e24 net: extend ubuf_info callback to ops structure, not committed.] Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- drivers/vhost/net.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 4b9151474a24..c988119723a8 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -371,12 +371,18 @@ static void vhost_zerocopy_signal_used(struct vhost_net *net, static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success) { - struct vhost_net_ubuf_ref *ubufs = ubuf->ctx; - struct vhost_virtqueue *vq = ubufs->vq; + struct vhost_net_ubuf_ref *ubufs; + struct vhost_virtqueue *vq; int cnt; - rcu_read_lock_bh(); + /* Only the final cloned skb reference completes the vhost descriptor. */ + if (!refcount_dec_and_test(&ubuf->refcnt)) + return; + + ubufs = ubuf->ctx; + vq = ubufs->vq; + rcu_read_lock_bh(); /* set len to mark this desc buffers done DMA */ vq->heads[ubuf->desc].len = success ? VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; -- 2.34.1

2 1

[PATCH OLK-6.6 v3 0/7] CVE-2026-74314
by Pu Lehui 29 Aug '26

29 Aug '26

Benjamin Tissoires (1): bpf: Do not walk twice the hash map on free Hou Tao (1): bpf: Factor out htab_elem_value helper() Justin Suess (1): bpf: Cancel special fields on map value recycle Kumar Kartikeya Dwivedi (1): bpf: Register dtor for freeing special fields Mykyta Yatsenko (2): bpf: htab: extract helper for freeing special structs bpf: Extract internal structs validation logic into helpers Pu Lehui (1): bpf: Fix kabi breakage for struct bpf_mem_alloc include/linux/bpf.h | 8 + include/linux/bpf_mem_alloc.h | 4 + kernel/bpf/arraymap.c | 12 +- kernel/bpf/hashtab.c | 198 +++++++++++++----- kernel/bpf/helpers.c | 6 + kernel/bpf/memalloc.c | 74 ++++++- kernel/bpf/syscall.c | 5 + .../selftests/bpf/prog_tests/linked_list.c | 33 +-- .../selftests/bpf/prog_tests/map_kptr.c | 10 +- .../testing/selftests/bpf/progs/linked_list.c | 51 +++++ 10 files changed, 306 insertions(+), 95 deletions(-) -- 2.34.1

2 8

[PATCH OLK-6.6] i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()
by Lin Ruifeng 29 Aug '26

29 Aug '26

From: Adrian Hunter <adrian.hunter(a)intel.com> stable inclusion from stable-v7.1.5 commit 8f851cab401c28287d536b1347d76f6e219c0db6 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17487 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 650716f23eac488c6696babdc7805f6a6b7427ad ] i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem). However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock. This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes. Remove the dependency on the bus device list and introduce a dedicated lookup table. Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock. Update the array when IBIs are enabled or disabled, so that it always reflects the set of devices allowed to generate IBIs. Also update when IBIs are freed, to cover the corner case when an IBI is freed without first being disabled (e.g. oldedev in i3c_master_add_i3c_dev_locked()). Move i3c_hci_addr_to_dev() into core.c, reimplement it using the new array, and add a lockdep assertion to enforce that hci->lock is held by callers. Demote a message in PIO and DMA IBI handling, from an error to a debug message, because there is a race window when the condition can arise normally. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Link: https://patch.msgid.link/20260612080107.11606-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/i3c/master/mipi-i3c-hci/core.c drivers/i3c/master/mipi-i3c-hci/hci.h [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/i3c/master/mipi-i3c-hci/core.c | 37 ++++++++++++++++++++++++-- drivers/i3c/master/mipi-i3c-hci/dma.c | 7 +++-- drivers/i3c/master/mipi-i3c-hci/hci.h | 1 + drivers/i3c/master/mipi-i3c-hci/ibi.h | 13 +-------- drivers/i3c/master/mipi-i3c-hci/pio.c | 7 +++-- 5 files changed, 47 insertions(+), 18 deletions(-) diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c index 8bceced3c305..c9039b6c8e3b 100644 --- a/drivers/i3c/master/mipi-i3c-hci/core.c +++ b/drivers/i3c/master/mipi-i3c-hci/core.c @@ -21,6 +21,7 @@ #include "ext_caps.h" #include "cmd.h" #include "dat.h" +#include "ibi.h" /* @@ -126,6 +127,7 @@ static inline struct i3c_hci *to_i3c_hci(struct i3c_master_controller *m) static int i3c_hci_bus_init(struct i3c_master_controller *m) { struct i3c_hci *hci = to_i3c_hci(m); + struct device *dev = hci->master.dev.parent; struct i3c_device_info info; int ret; @@ -148,6 +150,10 @@ static int i3c_hci_bus_init(struct i3c_master_controller *m) if (ret) return ret; + hci->ibi_devs = devm_kcalloc(dev, hci->DAT_entries, sizeof(*hci->ibi_devs), GFP_KERNEL); + if (!hci->ibi_devs) + return -ENOMEM; + ret = hci->io->init(hci); if (ret) return ret; @@ -484,14 +490,40 @@ static int i3c_hci_request_ibi(struct i3c_dev_desc *dev, return hci->io->request_ibi(hci, dev, req); } +static void __i3c_hci_disable_ibi(struct i3c_hci *hci, struct i3c_dev_desc *dev) +{ + struct i3c_hci_dev_data *dev_data = i3c_dev_get_master_data(dev); + + mipi_i3c_hci_dat_v1.set_flags(hci, dev_data->dat_idx, DAT_0_SIR_REJECT, 0); + scoped_guard(spinlock_irqsave, &hci->lock) + hci->ibi_devs[dev_data->dat_idx] = NULL; +} + static void i3c_hci_free_ibi(struct i3c_dev_desc *dev) { struct i3c_master_controller *m = i3c_dev_get_master(dev); struct i3c_hci *hci = to_i3c_hci(m); + /* Must ensure the IBI has been disabled */ + __i3c_hci_disable_ibi(hci, dev); hci->io->free_ibi(hci, dev); } +struct i3c_dev_desc *i3c_hci_addr_to_dev(struct i3c_hci *hci, unsigned int addr) +{ + int dat_idx; + + lockdep_assert_held(&hci->lock); + + for (dat_idx = 0; dat_idx < hci->DAT_entries; dat_idx++) { + struct i3c_dev_desc *dev = hci->ibi_devs[dat_idx]; + + if (dev && dev->info.dyn_addr == addr) + return dev; + } + return NULL; +} + static int i3c_hci_enable_ibi(struct i3c_dev_desc *dev) { struct i3c_master_controller *m = i3c_dev_get_master(dev); @@ -499,6 +531,8 @@ static int i3c_hci_enable_ibi(struct i3c_dev_desc *dev) struct i3c_hci_dev_data *dev_data = i3c_dev_get_master_data(dev); mipi_i3c_hci_dat_v1.clear_flags(hci, dev_data->dat_idx, DAT_0_SIR_REJECT, 0); + scoped_guard(spinlock_irqsave, &hci->lock) + hci->ibi_devs[dev_data->dat_idx] = dev; return i3c_master_enec_locked(m, dev->info.dyn_addr, I3C_CCC_EVENT_SIR); } @@ -506,9 +540,8 @@ static int i3c_hci_disable_ibi(struct i3c_dev_desc *dev) { struct i3c_master_controller *m = i3c_dev_get_master(dev); struct i3c_hci *hci = to_i3c_hci(m); - struct i3c_hci_dev_data *dev_data = i3c_dev_get_master_data(dev); - mipi_i3c_hci_dat_v1.set_flags(hci, dev_data->dat_idx, DAT_0_SIR_REJECT, 0); + __i3c_hci_disable_ibi(hci, dev); return i3c_master_disec_locked(m, dev->info.dyn_addr, I3C_CCC_EVENT_SIR); } diff --git a/drivers/i3c/master/mipi-i3c-hci/dma.c b/drivers/i3c/master/mipi-i3c-hci/dma.c index 624d00b853a5..8b1e27d8bb6a 100644 --- a/drivers/i3c/master/mipi-i3c-hci/dma.c +++ b/drivers/i3c/master/mipi-i3c-hci/dma.c @@ -663,8 +663,11 @@ static void hci_dma_process_ibi(struct i3c_hci *hci, struct hci_rh_data *rh) /* determine who this is for */ dev = i3c_hci_addr_to_dev(hci, ibi_addr); if (!dev) { - dev_err(&hci->master.dev, - "IBI for unknown device %#x\n", ibi_addr); + /* + * Either an IBI received just before IBI's were disabled, or + * the controller is broken. Assume the former. + */ + dev_dbg(&hci->master.dev, "IBI when not enabled at address %#x\n", ibi_addr); goto done; } diff --git a/drivers/i3c/master/mipi-i3c-hci/hci.h b/drivers/i3c/master/mipi-i3c-hci/hci.h index f109923f6c3f..7e84653d45b0 100644 --- a/drivers/i3c/master/mipi-i3c-hci/hci.h +++ b/drivers/i3c/master/mipi-i3c-hci/hci.h @@ -49,6 +49,7 @@ struct i3c_hci { unsigned int DAT_entries; unsigned int DAT_entry_size; void *DAT_data; + struct i3c_dev_desc **ibi_devs; unsigned int DCT_entries; unsigned int DCT_entry_size; u8 version_major; diff --git a/drivers/i3c/master/mipi-i3c-hci/ibi.h b/drivers/i3c/master/mipi-i3c-hci/ibi.h index e1f98e264da0..073ca67b7d04 100644 --- a/drivers/i3c/master/mipi-i3c-hci/ibi.h +++ b/drivers/i3c/master/mipi-i3c-hci/ibi.h @@ -26,17 +26,6 @@ #define IBI_DATA_LENGTH GENMASK(7, 0) /* handy helpers */ -static inline struct i3c_dev_desc * -i3c_hci_addr_to_dev(struct i3c_hci *hci, unsigned int addr) -{ - struct i3c_bus *bus = i3c_master_get_bus(&hci->master); - struct i3c_dev_desc *dev; - - i3c_bus_for_each_i3cdev(bus, dev) { - if (dev->info.dyn_addr == addr) - return dev; - } - return NULL; -} +struct i3c_dev_desc *i3c_hci_addr_to_dev(struct i3c_hci *hci, unsigned int addr); #endif diff --git a/drivers/i3c/master/mipi-i3c-hci/pio.c b/drivers/i3c/master/mipi-i3c-hci/pio.c index d0272aa93599..ba21d04a8d7a 100644 --- a/drivers/i3c/master/mipi-i3c-hci/pio.c +++ b/drivers/i3c/master/mipi-i3c-hci/pio.c @@ -833,8 +833,11 @@ static bool hci_pio_prep_new_ibi(struct i3c_hci *hci, struct hci_pio_data *pio) dev = i3c_hci_addr_to_dev(hci, ibi->addr); if (!dev) { - dev_err(&hci->master.dev, - "IBI for unknown device %#x\n", ibi->addr); + /* + * Either an IBI received just before IBI's were disabled, or + * the controller is broken. Assume the former. + */ + dev_dbg(&hci->master.dev, "IBI when not enabled at address %#x\n", ibi->addr); return true; } -- 2.34.1

2 1

[PATCH OLK-6.6 v3 0/7] CVE-2026-74314
by Pu Lehui 29 Aug '26

29 Aug '26

Benjamin Tissoires (1): bpf: Do not walk twice the hash map on free Hou Tao (1): bpf: Factor out htab_elem_value helper() Justin Suess (1): bpf: Cancel special fields on map value recycle Kumar Kartikeya Dwivedi (1): bpf: Register dtor for freeing special fields Mykyta Yatsenko (2): bpf: htab: extract helper for freeing special structs bpf: Extract internal structs validation logic into helpers Pu Lehui (1): bpf: Fix kabi breakage for struct bpf_mem_alloc include/linux/bpf.h | 8 + include/linux/bpf_mem_alloc.h | 4 + kernel/bpf/arraymap.c | 12 +- kernel/bpf/hashtab.c | 198 +++++++++++++----- kernel/bpf/helpers.c | 6 + kernel/bpf/memalloc.c | 74 ++++++- kernel/bpf/syscall.c | 5 + .../selftests/bpf/prog_tests/linked_list.c | 33 +-- .../selftests/bpf/prog_tests/map_kptr.c | 10 +- .../testing/selftests/bpf/progs/linked_list.c | 51 +++++ 10 files changed, 306 insertions(+), 95 deletions(-) -- 2.34.1

2 8

[PATCH openEuler-1.0-LTS] vhost/net: complete zerocopy ubufs only once
by Jiacheng Yu 29 Aug '26

29 Aug '26

From: Qing Ming <a0yami(a)mailbox.org> mainline inclusion from mainline-v7.2-rc1 commit 8f6898fe80794f2d7c3d38c1158c806e4074a1c4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17657 CVE: CVE-2026-74310 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs. Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support") Signed-off-by: Qing Ming <a0yami(a)mailbox.org> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Message-ID: <20260601104300.197210-1-a0yami(a)mailbox.org> Conficts: drivers/vhost/net.c [7ab4f16f9e24 net: extend ubuf_info callback to ops structure, not committed.] Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- drivers/vhost/net.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 4b9151474a24..c988119723a8 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -371,12 +371,18 @@ static void vhost_zerocopy_signal_used(struct vhost_net *net, static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success) { - struct vhost_net_ubuf_ref *ubufs = ubuf->ctx; - struct vhost_virtqueue *vq = ubufs->vq; + struct vhost_net_ubuf_ref *ubufs; + struct vhost_virtqueue *vq; int cnt; - rcu_read_lock_bh(); + /* Only the final cloned skb reference completes the vhost descriptor. */ + if (!refcount_dec_and_test(&ubuf->refcnt)) + return; + + ubufs = ubuf->ctx; + vq = ubufs->vq; + rcu_read_lock_bh(); /* set len to mark this desc buffers done DMA */ vq->heads[ubuf->desc].len = success ? VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; -- 2.34.1

2 1

[PATCH OLK-5.10] vhost/net: complete zerocopy ubufs only once
by Jiacheng Yu 29 Aug '26

29 Aug '26

From: Qing Ming <a0yami(a)mailbox.org> mainline inclusion from mainline-v7.2-rc1 commit 8f6898fe80794f2d7c3d38c1158c806e4074a1c4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17657 CVE: CVE-2026-74310 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs. Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support") Signed-off-by: Qing Ming <a0yami(a)mailbox.org> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Message-ID: <20260601104300.197210-1-a0yami(a)mailbox.org> Conflicts: drivers/vhost/net.c [7ab4f16f9e24 net: extend ubuf_info callback to ops structure, not committed.] Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- drivers/vhost/net.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index f5503306457f..8320e63cefa5 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -383,12 +383,18 @@ static void vhost_zerocopy_signal_used(struct vhost_net *net, static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success) { - struct vhost_net_ubuf_ref *ubufs = ubuf->ctx; - struct vhost_virtqueue *vq = ubufs->vq; + struct vhost_net_ubuf_ref *ubufs; + struct vhost_virtqueue *vq; int cnt; - rcu_read_lock_bh(); + /* Only the final cloned skb reference completes the vhost descriptor. */ + if (!refcount_dec_and_test(&ubuf->refcnt)) + return; + + ubufs = ubuf->ctx; + vq = ubufs->vq; + rcu_read_lock_bh(); /* set len to mark this desc buffers done DMA */ vq->heads[ubuf->desc].len = success ? VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] iommu/amd: Bound the early ACPI HID map
by Zhang Yuwei 29 Aug '26

29 Aug '26

From: Pengpeng Hou <pengpeng(a)iscas.ac.cn> stable inclusion from stable-v6.6.148 commit 1e31d2394e0db69541b1591d46c5ad6431c81db3 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18558 CVE: CVE-2026-68325 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fb80117fddb5b477218dc99bb53911b72c3847f8 ] The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> Reviewed-by: Ankit Soni <Ankit.Soni(a)amd.com> Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Conflicts: drivers/iommu/amd_iommu_init.c drivers/iommu/amd/init.c [context conflict] Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> --- drivers/iommu/amd_iommu_init.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 9903fd400eb2..7b2757e64c3a 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -2964,6 +2964,12 @@ static int __init parse_ivrs_acpihid(char *str) return 1; } + if (early_acpihid_map_size == EARLY_MAP_SIZE) { + pr_err("AMD-Vi: Early ACPI HID map overflow - ignoring ivrs_acpihid%s\n", + str); + return 1; + } + i = early_acpihid_map_size++; memcpy(early_acpihid_map[i].hid, hid, strlen(hid)); memcpy(early_acpihid_map[i].uid, uid, strlen(uid)); -- 2.22.0

2 1

[PATCH OLK-6.6] iommu/iommufd: Fix IOPF group ownership UAF
by Zhang Yuwei 29 Aug '26

29 Aug '26

From: Peiyang He <peiyang_he(a)smail.nju.edu.cn> mainline inclusion from mainline-v7.2-rc6 commit 738e6f32e61d80b554e37015ecb7bc620b88001c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17736 CVE: CVE-2026-74520 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- iopf_group_alloc() links each last-page IOPF group into the generic IOPF pending list before invoking the domain fault handler. iommufd_fault_iopf_handler() also queued an accepted group in the IOMMUFD deliver list without removing it from the generic pending list. When detach or HWPT replacement drops the device's IOPF reference count to zero, an IOMMU driver may call iopf_queue_remove_device(). That function responds to and frees groups through the generic pending list without removing the same groups from IOMMUFD's deliver list or response xarray. A later read, response, or cleanup can then access the freed group and cause a UAF. Fix this by dequeuing an accepted group from the generic pending list before IOMMUFD queues it for userspace response. Make iopf_group_response() send a response regardless of pending-list membership, so the dequeued group can still be completed by IOMMUFD. Link: https://patch.msgid.link/r/3CFD314D0FE4D7EC+20260720085017.3998878-2-peiyan… Closes: https://lore.kernel.org/all/B4F28798E2E784CA+d29f723c-b2b5-4b67-8d1c-4f7b9b… Fixes: 34765cbc679c ("iommufd: Associate fault object with iommufd_hw_pgtable") Cc: stable(a)vger.kernel.org Tested-by: Peiyang He <peiyang_he(a)smail.nju.edu.cn> Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Peiyang He <peiyang_he(a)smail.nju.edu.cn> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Conflicts: include/linux/iommu.h drivers/iommu/iommufd/eventq.c drivers/iommu/iommufd/fault.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/iommu/io-pgfault.c | 24 +++++++++++++++++++----- drivers/iommu/iommufd/fault.c | 2 ++ include/linux/iommu.h | 5 +++++ 3 files changed, 26 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c index 150b11e5b5ac..9f4a7da7f0f3 100644 --- a/drivers/iommu/io-pgfault.c +++ b/drivers/iommu/io-pgfault.c @@ -338,16 +338,30 @@ void iopf_group_response(struct iopf_group *group, .code = status, }; - /* Only send response if there is a fault report pending */ mutex_lock(&fault_param->lock); - if (!list_empty(&group->pending_node)) { - ops->page_response(dev, &group->last_fault, &resp); - list_del_init(&group->pending_node); - } + ops->page_response(dev, &group->last_fault, &resp); + list_del_init(&group->pending_node); mutex_unlock(&fault_param->lock); } EXPORT_SYMBOL_GPL(iopf_group_response); +/** + * iopf_group_dequeue - Dequeue a page fault group from the pending list + * @group: the group to dequeue + * + * The fault handler is responsible for responding to the group after + * this function returns. + */ +void iopf_group_dequeue(struct iopf_group *group) +{ + struct iommu_fault_param *fault_param = group->fault_param; + + mutex_lock(&fault_param->lock); + list_del_init(&group->pending_node); + mutex_unlock(&fault_param->lock); +} +EXPORT_SYMBOL_GPL(iopf_group_dequeue); + /** * iopf_queue_discard_partial - Remove all pending partial fault * @queue: the queue whose partial faults need to be discarded diff --git a/drivers/iommu/iommufd/fault.c b/drivers/iommu/iommufd/fault.c index 854756d5abc0..b6a669d06110 100644 --- a/drivers/iommu/iommufd/fault.c +++ b/drivers/iommu/iommufd/fault.c @@ -449,6 +449,8 @@ int iommufd_fault_iopf_handler(struct iopf_group *group) hwpt = group->attach_handle->domain->fault_data; fault = hwpt->fault; + iopf_group_dequeue(group); + mutex_lock(&fault->mutex); list_add_tail(&group_extend->node, &fault->deliver); mutex_unlock(&fault->mutex); diff --git a/include/linux/iommu.h b/include/linux/iommu.h index bd052f760eba..178e9ccef23a 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -1940,6 +1940,7 @@ void iopf_free_group(struct iopf_group *group); int iommu_report_device_fault(struct device *dev, struct iopf_fault *evt); void iopf_group_response(struct iopf_group *group, enum iommu_page_response_code status); +void iopf_group_dequeue(struct iopf_group *group); #else static inline int iopf_queue_add_device(struct iopf_queue *queue, struct device *dev) @@ -1985,6 +1986,10 @@ static inline void iopf_group_response(struct iopf_group *group, enum iommu_page_response_code status) { } + +static inline void iopf_group_dequeue(struct iopf_group *group) +{ +} #endif /* CONFIG_IOMMU_IOPF */ #ifdef CONFIG_IOMMU_KSVA -- 2.22.0

2 1

[PATCH openEuler-1.0-LTS] ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()
by JiangJieHua 29 Aug '26

29 Aug '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v7.2-rc3 commit 7b19c0f81ed1fdaec6bc522569be367199a9edf3 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/9704 CVE: CVE-2026-72323 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Zero Day Initiative <zdi-disclosures(a)trendmicro.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260705181756.963063-2-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/ipv4/igmp.c [For 4.19, get_random_u32_below() is not available, so igmp_ifc_start_timer() retains the original prandom_u32() % delay approach. The remaining refcount logic and the newly added in_dev_hold_safe() parts are consistent with upstream.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- include/linux/inetdevice.h | 5 +++++ net/ipv4/igmp.c | 14 +++++++++----- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h index a64f21a97369a..002f1de9a30f4 100644 --- a/include/linux/inetdevice.h +++ b/include/linux/inetdevice.h @@ -255,6 +255,11 @@ static inline void in_dev_put(struct in_device *idev) #define __in_dev_put(idev) refcount_dec(&(idev)->refcnt) #define in_dev_hold(idev) refcount_inc(&(idev)->refcnt) +static inline bool in_dev_hold_safe(struct in_device *idev) +{ + return refcount_inc_not_zero(&idev->refcnt); +} + #endif /* __KERNEL__ */ static __inline__ __be32 inet_make_mask(int logmask) diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c index c4b396968acd6..ed9ef8430c14f 100644 --- a/net/ipv4/igmp.c +++ b/net/ipv4/igmp.c @@ -237,16 +237,20 @@ static void igmp_gq_start_timer(struct in_device *in_dev) return; in_dev->mr_gq_running = 1; - if (!mod_timer(&in_dev->mr_gq_timer, exp)) - in_dev_hold(in_dev); + if (in_dev_hold_safe(in_dev)) { + if (mod_timer(&in_dev->mr_gq_timer, exp)) + in_dev_put(in_dev); + } } static void igmp_ifc_start_timer(struct in_device *in_dev, int delay) { - int tv = prandom_u32() % delay; + if (in_dev_hold_safe(in_dev)) { + int tv = prandom_u32() % (delay); - if (!mod_timer(&in_dev->mr_ifc_timer, jiffies+tv+2)) - in_dev_hold(in_dev); + if (mod_timer(&in_dev->mr_ifc_timer, jiffies + tv + 2)) + in_dev_put(in_dev); + } } static void igmp_mod_timer(struct ip_mc_list *im, int max_delay) -- 2.33.8

2 1

[PATCH openEuler-1.0-LTS] ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD
by JiangJieHua 29 Aug '26

29 Aug '26

From: Linmao Li <lilinmao(a)kylinos.cn> mainline inclusion from mainline-v7.2-rc1 commit 627ac78f2741e2ebd2225e2e953b6964a8a9182f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18025 CVE: CVE-2026-74398 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released. Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing to workqueue") Signed-off-by: Linmao Li <lilinmao(a)kylinos.cn> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260513025509.3776405-1-lilinmao@kylinos.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv6/addrconf.c [Contextual differences between the branch and mainline required adaptation during patch application. The functional changes from the upstream commit are preserved.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/ipv6/addrconf.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 98a24b5e6f036..7b8dda47d3855 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -2020,16 +2020,18 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp) struct inet6_dev *idev = ifp->idev; struct net *net = dev_net(ifp->idev->dev); - if (addrconf_dad_end(ifp)) { + spin_lock_bh(&ifp->lock); + + if (ifp->state != INET6_IFADDR_STATE_DAD) { + spin_unlock_bh(&ifp->lock); in6_ifa_put(ifp); return; } + ifp->state = INET6_IFADDR_STATE_POSTDAD; net_info_ratelimited("%s: IPv6 duplicate address %pI6c used by %pM detected!\n", ifp->idev->dev->name, &ifp->addr, eth_hdr(skb)->h_source); - spin_lock_bh(&ifp->lock); - if (ifp->flags & IFA_F_STABLE_PRIVACY) { struct in6_addr new_addr; struct inet6_ifaddr *ifp2; @@ -2077,6 +2079,11 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp) in6_ifa_put(ifp2); lock_errdad: spin_lock_bh(&ifp->lock); + if (ifp->state != INET6_IFADDR_STATE_POSTDAD) { + spin_unlock_bh(&ifp->lock); + in6_ifa_put(ifp); + return; + } } errdad: -- 2.33.8

2 1

[PATCH openEuler-1.0-LTS] iommu/amd: Bound the early ACPI HID map
by Zhang Yuwei 29 Aug '26

29 Aug '26

From: Pengpeng Hou <pengpeng(a)iscas.ac.cn> stable inclusion from stable-v6.6.148 commit 1e31d2394e0db69541b1591d46c5ad6431c81db3 category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fb80117fddb5b477218dc99bb53911b72c3847f8 ] The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> Reviewed-by: Ankit Soni <Ankit.Soni(a)amd.com> Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Conflicts: drivers/iommu/amd_iommu_init.c drivers/iommu/amd/init.c [context conflict] Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> --- drivers/iommu/amd_iommu_init.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 9903fd400eb2..7b2757e64c3a 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -2964,6 +2964,12 @@ static int __init parse_ivrs_acpihid(char *str) return 1; } + if (early_acpihid_map_size == EARLY_MAP_SIZE) { + pr_err("AMD-Vi: Early ACPI HID map overflow - ignoring ivrs_acpihid%s\n", + str); + return 1; + } + i = early_acpihid_map_size++; memcpy(early_acpihid_map[i].hid, hid, strlen(hid)); memcpy(early_acpihid_map[i].uid, uid, strlen(uid)); -- 2.22.0

2 1

[PATCH OLK-6.6] tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg
by Tengda Wu 29 Aug '26

29 Aug '26

From: "Masami Hiramatsu (Google)" <mhiramat(a)kernel.org> mainline inclusion from mainline-v7.2-rc2 commit 251a8fe1b9aedccd298b77bc28426d564c5a923f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18523 CVE: CVE-2026-80607 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Sashiko found that user can cause this WARN_ON_ONCE() easily with adding a kprobe event based on a raw address with BTF parameter. Since this is not an unexpected condition, remove the WARN_ON_ONCE(). Link: https://lore.kernel.org/all/178177265367.2059927.13789953014706792126.stgit… Link: https://sashiko.dev/#/patchset/178165816303.269421.7302603996990753309.stgi… Reported-by: Sashiko <sashiko-bot(a)kernel.org> Fixes: b576e09701c7 ("tracing/probes: Support function parameters if BTF is available") Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Conflicts: kernel/trace/trace_probe.c [A slight difference in the warning condition arises from commit 69efd863a78, which is not yet merged because it is a feature patch] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/trace_probe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c index 8980f4ecd020..066e154b91ee 100644 --- a/kernel/trace/trace_probe.c +++ b/kernel/trace/trace_probe.c @@ -619,7 +619,7 @@ static int parse_btf_arg(char *varname, int i, is_ptr, ret; u32 tid; - if (WARN_ON_ONCE(!ctx->funcname)) + if (!ctx->funcname) return -EINVAL; is_ptr = split_next_field(varname, &field, ctx); -- 2.34.1

2 1

[PATCH OLK-6.6] tls: rx: restore msg_iter before TLS 1.3 optimistic retry
by superdcc97＠163.com 29 Aug '26

29 Aug '26

From: Jérémy Jean <Jeremy.Jean(a)oss.cyber.gouv.fr> mainline inclusion from mainline-v7.2-rc7 commit 1c8629651cb54f7b51db8fc0b1a9944e4a4b0f5e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18180 CVE: CVE-2026-74611 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- tls_decrypt_sg() advances msg->msg_iter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tls_decrypt_sw() retries into a kernel skb, but leaves the iterator advanced. The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLS_RX_EXPECT_NO_PAD. Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy. Add a selftest which sends a TLS 1.3 control record with TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length. Fixes: ce61327ce989 ("tls: rx: support optimistic decrypt to user buffer with TLS 1.3") Cc: stable(a)vger.kernel.org Signed-off-by: Jérémy Jean <Jeremy.Jean(a)oss.cyber.gouv.fr> Link: https://patch.msgid.link/20260804125528.2139928-1-Jeremy.Jean@oss.cyber.gou… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: tools/testing/selftests/net/tls.c [commit dc54b813df63 ("selftests: tls: add test with a partially invalid iov"), 555f0edb9ff0 ("selftests: tls: add rekey tests") and b2e584aa3c71 ("selftests: tls: add key_generation argument to tls_crypto_info_init") are not backport, which lead to conflicts] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/tls/tls_sw.c | 2 ++ tools/testing/selftests/net/tls.c | 58 +++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 934f95bab928..9361e0f84571 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -1733,18 +1733,20 @@ tls_decrypt_sw(struct sock *sk, struct tls_context *tls_ctx, if (err == -EBADMSG) TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSDECRYPTERROR); return err; } /* keep going even for ->async, the code below is TLS 1.3 */ /* If opportunistic TLS 1.3 ZC failed retry without ZC */ if (unlikely(darg->zc && prot->version == TLS_1_3_VERSION && darg->tail != TLS_RECORD_TYPE_DATA)) { + iov_iter_revert(&msg->msg_iter, strp_msg(darg->skb)->full_len - + prot->overhead_size); darg->zc = false; if (!darg->tail) TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSRXNOPADVIOL); TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSDECRYPTRETRY); return tls_decrypt_sw(sk, tls_ctx, msg, darg); } pad = tls_padding_length(prot, darg->skb, darg); if (pad < 0) { diff --git a/tools/testing/selftests/net/tls.c b/tools/testing/selftests/net/tls.c index bc36c91c4480..e0d6cfb825ae 100644 --- a/tools/testing/selftests/net/tls.c +++ b/tools/testing/selftests/net/tls.c @@ -2108,18 +2108,76 @@ TEST(prequeue) { ASSERT_EQ(setsockopt(cfd, SOL_TLS, TLS_RX, &tls12, tls12.len), 0); EXPECT_EQ(recv(cfd, buf2, sizeof(buf2), MSG_WAITALL), sizeof(buf2)); EXPECT_EQ(memcmp(buf, buf2, sizeof(buf)), 0); close(fd); close(cfd); } +#define TLS_RECORD_TYPE_HANDSHAKE 0x16 + +TEST_F(tls_basic, recvmsg_nopad_retry_iov) +{ + char payload[32]; + char first_iov[sizeof(payload)]; + char later_iov[sizeof(payload) * 2]; + char expected_later_iov[sizeof(later_iov)]; + char cbuf[CMSG_SPACE(sizeof(char))]; + struct tls_crypto_info_keys tls13; + struct iovec iov[] = { + { .iov_base = first_iov, .iov_len = sizeof(first_iov) }, + { .iov_base = later_iov, .iov_len = sizeof(later_iov) }, + }; + struct msghdr msg = { + .msg_iov = iov, + .msg_iovlen = ARRAY_SIZE(iov), + .msg_control = cbuf, + .msg_controllen = sizeof(cbuf), + }; + int one = 1; + int ret; + int i; + + if (self->notls) + SKIP(return, "no TLS support"); + + tls_crypto_info_init(TLS_1_3_VERSION, TLS_CIPHER_AES_GCM_128, + &tls13); + + ret = setsockopt(self->fd, SOL_TLS, TLS_TX, &tls13, tls13.len); + ASSERT_EQ(ret, 0); + + ret = setsockopt(self->cfd, SOL_TLS, TLS_RX, &tls13, tls13.len); + ASSERT_EQ(ret, 0); + + ret = setsockopt(self->cfd, SOL_TLS, TLS_RX_EXPECT_NO_PAD, + &one, sizeof(one)); + ASSERT_EQ(ret, 0); + + for (i = 0; i < sizeof(payload); i++) + payload[i] = 0x40 + i; + memset(first_iov, 0xa5, sizeof(first_iov)); + memset(later_iov, 0x5a, sizeof(later_iov)); + memset(expected_later_iov, 0x5a, sizeof(expected_later_iov)); + + /* A control record forces optimistic TLS 1.3 RX to retry. */ + ret = tls_send_cmsg(self->fd, TLS_RECORD_TYPE_HANDSHAKE, + payload, sizeof(payload), 0); + ASSERT_EQ(ret, sizeof(payload)); + + ret = recvmsg(self->cfd, &msg, 0); + ASSERT_EQ(ret, sizeof(payload)); + EXPECT_EQ(memcmp(first_iov, payload, sizeof(payload)), 0); + EXPECT_EQ(memcmp(later_iov, expected_later_iov, + sizeof(later_iov)), 0); +} + static void __attribute__((constructor)) fips_check(void) { int res; FILE *f; f = fopen("/proc/sys/crypto/fips_enabled", "r"); if (f) { res = fscanf(f, "%d", &fips_enabled); if (res != 1) ksft_print_msg("ERROR: Couldn't read /proc/sys/crypto/fips_enabled\n"); -- 2.43.0

2 1

[PATCH OLK-6.6] vhost: reset the vring metadata cache on vring reconfiguration
by Lin Ruifeng 29 Aug '26

29 Aug '26

From: Jun Yang <junvyyang(a)tencent.com> stable inclusion from stable-v6.6.152 commit cf363a7a02ce132ef1f58084fdb13e1a3b7da7e7 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18149 CVE: CVE-2026-74580 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit de845981da67a6b049080c87e605130b0c30adc5 upstream. vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated: if (vhost_vq_meta_fetch(vq, addr, len, type)) return true; The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vq_access_ok() and vq_log_used_access_ok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vq_meta_prefetch() hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps translating through the old mapping as map->addr + addr - map->start for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlb_access_ok()'s slow path. Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache") Cc: stable(a)vger.kernel.org Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Jun Yang <junvyyang(a)tencent.com> Message-ID: <20260803014823.68623-1-juny24602(a)gmail.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/vhost/vhost.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index a58be2369fdc..5f4ffc947833 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -1963,6 +1963,14 @@ static long vhost_vring_set_num_addr(struct vhost_dev *d, BUG(); } + /* + * The metadata cache holds the IOTLB mapping that backed the previous + * desc/avail/used addresses and vring size, both of which are being + * replaced here. iotlb_access_ok() takes a cache hit as proof that the + * region was validated, so the stale entries have to go. + */ + __vhost_vq_meta_reset(vq); + mutex_unlock(&vq->mutex); return r; -- 2.34.1

2 1

[PATCH OLK-6.6 v2 0/7] CVE-2026-74314
by Pu Lehui 29 Aug '26

29 Aug '26

Benjamin Tissoires (1): bpf: Do not walk twice the hash map on free Hou Tao (1): bpf: Factor out htab_elem_value helper() Justin Suess (1): bpf: Cancel special fields on map value recycle Kumar Kartikeya Dwivedi (1): bpf: Register dtor for freeing special fields Mykyta Yatsenko (2): bpf: htab: extract helper for freeing special structs bpf: Extract internal structs validation logic into helpers Pu Lehui (1): bpf: Fix kabi breakage for struct bpf_mem_alloc include/linux/bpf.h | 8 + include/linux/bpf_mem_alloc.h | 4 + kernel/bpf/arraymap.c | 12 +- kernel/bpf/hashtab.c | 198 +++++++++++++----- kernel/bpf/helpers.c | 6 + kernel/bpf/memalloc.c | 72 ++++++- kernel/bpf/syscall.c | 5 + .../selftests/bpf/prog_tests/linked_list.c | 33 +-- .../selftests/bpf/prog_tests/map_kptr.c | 10 +- .../testing/selftests/bpf/progs/linked_list.c | 51 +++++ 10 files changed, 304 insertions(+), 95 deletions(-) -- 2.34.1

2 8

[PATCH OLK-5.10] vhost: reset the vring metadata cache on vring reconfiguration
by Lin Ruifeng 29 Aug '26

29 Aug '26

From: Jun Yang <junvyyang(a)tencent.com> stable inclusion from stable-v5.10.265 commit 5224bd37e37d36076a550d99b2aebba33939fd95 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18149 CVE: CVE-2026-74580 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit de845981da67a6b049080c87e605130b0c30adc5 upstream. vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated: if (vhost_vq_meta_fetch(vq, addr, len, type)) return true; The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vq_access_ok() and vq_log_used_access_ok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vq_meta_prefetch() hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps translating through the old mapping as map->addr + addr - map->start for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlb_access_ok()'s slow path. Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache") Cc: stable(a)vger.kernel.org Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Jun Yang <junvyyang(a)tencent.com> Message-ID: <20260803014823.68623-1-juny24602(a)gmail.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/vhost/vhost.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 2131dd299638..507ad80ee673 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -1623,6 +1623,14 @@ static long vhost_vring_set_num_addr(struct vhost_dev *d, BUG(); } + /* + * The metadata cache holds the IOTLB mapping that backed the previous + * desc/avail/used addresses and vring size, both of which are being + * replaced here. iotlb_access_ok() takes a cache hit as proof that the + * region was validated, so the stale entries have to go. + */ + __vhost_vq_meta_reset(vq); + mutex_unlock(&vq->mutex); return r; -- 2.34.1

2 1

[PATCH OLK-6.6] perf: Reject exited events as group leaders
by Luo Gengkun 29 Aug '26

29 Aug '26

From: Kyle Zeng <kylebot(a)openai.com> mainline inclusion from mainline-v7.2 commit fa091f46c3833fb22384f10eade2b4e1e1d0b278 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18336 CVE: CVE-2026-74753 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state and detaches their group relationships. The event's file descriptor can remain open, however, and perf_event_open() currently accepts that event as a group leader because its early validation rejects only REVOKED and DEAD events. A new sibling can consequently be linked to the detached leader. When the leader is closed, perf_group_detach() observes that its PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The sibling then retains a group_leader pointer to the freed event. Reject group leaders in the EXIT state. Perform the check while holding the shared context mutex so that an exec in the target task cannot detach the leader between validation and group attachment. [peterz: make the earlier test fully consistent] Fixes: 037a3c43edfb ("perf/core: Detach event groups during remove_on_exec") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng <kylebot(a)openai.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://patch.msgid.link/20260806205655.75722-1-kylebot@openai.com Conflicts: kernel/events/core.c [Upstream fa091f46c3833 ("perf: Reject exited events as group leaders") rejects EXIT-state group leaders in two spots: the early fd validation and a recheck under ctx::mutex. The downstream baseline predates the fd_file()/PERF_EVENT_STATE_REVOKED refactor present in the upstream base: there is no fd_file() helper and no REVOKED event-state in the downstream enum (only PERF_EVENT_STATE_EXIT). Keep the downstream perf_fget_light()/group.file->private_data accessor instead of the absent fd_file(group), and add the EXIT-state rejection with -ENODEV/goto err_fd right after retrieving the leader. This achieves the same early-validation safety as the upstream change. The second hunk (recheck under ctx::mutex with goto err_locked) applies verbatim.] Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index 6916dc78b0e7..a388eb764659 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -12678,6 +12678,10 @@ SYSCALL_DEFINE5(perf_event_open, if (err) goto err_fd; group_leader = group.file->private_data; + if (group_leader->state <= PERF_EVENT_STATE_EXIT) { + err = -ENODEV; + goto err_group_fd; + } if (flags & PERF_FLAG_FD_OUTPUT) output_event = group_leader; if (flags & PERF_FLAG_FD_NO_GROUP) @@ -12805,6 +12809,12 @@ SYSCALL_DEFINE5(perf_event_open, if (group_leader->ctx != ctx) goto err_locked; + /* Recheck under ctx::mutex to serialize against remove-on-exec. */ + if (group_leader->state <= PERF_EVENT_STATE_EXIT) { + err = -ENODEV; + goto err_locked; + } + /* * Only a group leader can be exclusive or pinned */ -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] macvlan: inherit needed_headroom and needed_tailroom from lowerdev
by JiangJieHua 29 Aug '26

29 Aug '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v7.2 commit cef51860becd9700217c81732ca1eb1ea6ed6fe1 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18331 CVE: CVE-2026-74743 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Reported-by: Tangxin Xie <xietangxin(a)h-partners.com> Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5W… Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Hangbin Liu <liuhangbin(a)kylinos.cn> Link: https://patch.msgid.link/20260806141938.287660-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/macvlan.c [4.19 uses manual gso_max_size/gso_max_segs assignment instead of netif_inherit_tso_max() in macvlan_device_event() NETDEV_FEAT_CHANGE handler. The conflict is resolved by keeping 4.19's existing TSO inheritance and applying the new needed_headroom/needed_tailroom inheritance from the upstream patch.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- drivers/net/macvlan.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c index 0f2a2e6705142..38e0386659aca 100644 --- a/drivers/net/macvlan.c +++ b/drivers/net/macvlan.c @@ -883,7 +883,8 @@ static int macvlan_init(struct net_device *dev) dev->gso_max_size = lowerdev->gso_max_size; dev->gso_max_segs = lowerdev->gso_max_segs; dev->hard_header_len = lowerdev->hard_header_len; - + dev->needed_headroom = lowerdev->needed_headroom; + dev->needed_tailroom = lowerdev->needed_tailroom; macvlan_set_lockdep_class(dev); vlan->pcpu_stats = netdev_alloc_pcpu_stats(struct vlan_pcpu_stats); @@ -1682,6 +1683,8 @@ static int macvlan_device_event(struct notifier_block *unused, list_for_each_entry(vlan, &port->vlans, list) { vlan->dev->gso_max_size = dev->gso_max_size; vlan->dev->gso_max_segs = dev->gso_max_segs; + vlan->dev->needed_headroom = dev->needed_headroom; + vlan->dev->needed_tailroom = dev->needed_tailroom; netdev_update_features(vlan->dev); } break; -- 2.33.8

2 2

[PATCH openEuler-1.0-LTS] ipvlan: inherit needed_headroom and needed_tailroom from phy_dev
by JiangJieHua 29 Aug '26

29 Aug '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v7.2 commit e16e960d55a40d36bd7c2494cc005e757dc9a1ef category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18377 CVE: CVE-2026-74744 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Reported-by: syzbot+1f9fd0f4b601cf88d6e6(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a720a21.40259c87.584f4.04bb.GAE@google.com/… Reported-by: Tangxin Xie <xietangxin(a)h-partners.com> Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5W… Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Hangbin Liu <liuhangbin(a)kylinos.cn> Link: https://patch.msgid.link/20260806103857.115541-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ipvlan/ipvlan_main.c [The upstream patch expects netif_inherit_tso_max() helper in the NETDEV_FEAT_CHANGE event handler, but 4.19 uses direct assignments to gso_max_size and gso_max_segs. Resolved by keeping the 4.19 TSO inheritance style (direct assignment) and applying the new headroom/ tailroom inheritance from the patch. This preserves the upstream fix semantics while maintaining compatibility with the 4.19 codebase.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- drivers/net/ipvlan/ipvlan_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c index 9057cdf9b2162..ed1a5af42b072 100644 --- a/drivers/net/ipvlan/ipvlan_main.c +++ b/drivers/net/ipvlan/ipvlan_main.c @@ -258,6 +258,8 @@ static int ipvlan_init(struct net_device *dev) dev->gso_max_size = phy_dev->gso_max_size; dev->gso_max_segs = phy_dev->gso_max_segs; dev->hard_header_len = phy_dev->hard_header_len; + dev->needed_headroom = phy_dev->needed_headroom; + dev->needed_tailroom = phy_dev->needed_tailroom; netdev_lockdep_set_classes(dev); @@ -899,6 +901,8 @@ static int ipvlan_device_event(struct notifier_block *unused, list_for_each_entry(ipvlan, &port->ipvlans, pnode) { ipvlan->dev->gso_max_size = dev->gso_max_size; ipvlan->dev->gso_max_segs = dev->gso_max_segs; + ipvlan->dev->needed_headroom = dev->needed_headroom; + ipvlan->dev->needed_tailroom = dev->needed_tailroom; netdev_update_features(ipvlan->dev); } break; -- 2.33.8

2 2

[PATCH openEuler-1.0-LTS] ipv6: mcast: Fix potential UAF in MLD delayed work
by JiangJieHua 29 Aug '26

29 Aug '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v7.2-rc3 commit 9b26518b6896a16b809b1e42986f4ebac7bccc1e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17356 CVE: CVE-2026-72322 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260705181756.963063-3-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: include/net/addrconf.h net/ipv6/mcast.c [addrconf.h: the upstream hunk context after in6_dev_hold() references ip6_ignore_linkdown(), which does not exist in 4.19, so only the new in6_dev_hold_safe() helper is added and the ip6_ignore_linkdown() context is dropped. mcast.c: 4.19 use timers (mld_gq_start_timer/mld_ifc_start_timer/ mld_dad_start_timer + mod_timer) instead of workqueue (mld_*_start_work + mod_delayed_work); igmp6_event_query/report have no workqueue queues, so those hunks are not applicable. The refcount fix is applied to the three _start_timer functions instead, preserving the upstream semantics.In 4.19, the `igmp6_event_query/report` hunks are dropped entirely (sync implementation, no workqueue queues); the target's existing refcount sites are already covered by the three `_start_timer` fixes.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- include/net/addrconf.h | 5 +++++ net/ipv6/mcast.c | 18 ++++++++++++------ 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/include/net/addrconf.h b/include/net/addrconf.h index 10d270f004f0d..26f0a5bc234be 100644 --- a/include/net/addrconf.h +++ b/include/net/addrconf.h @@ -425,6 +425,11 @@ static inline void in6_dev_hold(struct inet6_dev *idev) refcount_inc(&idev->refcnt); } +static inline bool in6_dev_hold_safe(struct inet6_dev *idev) +{ + return refcount_inc_not_zero(&idev->refcnt); +} + void inet6_ifa_finish_destroy(struct inet6_ifaddr *ifp); static inline void in6_ifa_put(struct inet6_ifaddr *ifp) diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c index bb484fe27e137..787800af097a5 100644 --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -1037,8 +1037,10 @@ static void mld_gq_start_timer(struct inet6_dev *idev) unsigned long tv = prandom_u32() % idev->mc_maxdelay; idev->mc_gq_running = 1; - if (!mod_timer(&idev->mc_gq_timer, jiffies+tv+2)) - in6_dev_hold(idev); + if (in6_dev_hold_safe(idev)) { + if (mod_timer(&idev->mc_gq_timer, jiffies+tv+2)) + in6_dev_put(idev); + } } static void mld_gq_stop_timer(struct inet6_dev *idev) @@ -1052,8 +1054,10 @@ static void mld_ifc_start_timer(struct inet6_dev *idev, unsigned long delay) { unsigned long tv = prandom_u32() % delay; - if (!mod_timer(&idev->mc_ifc_timer, jiffies+tv+2)) - in6_dev_hold(idev); + if (in6_dev_hold_safe(idev)) { + if (mod_timer(&idev->mc_ifc_timer, jiffies+tv+2)) + in6_dev_put(idev); + } } static void mld_ifc_stop_timer(struct inet6_dev *idev) @@ -1067,8 +1071,10 @@ static void mld_dad_start_timer(struct inet6_dev *idev, unsigned long delay) { unsigned long tv = prandom_u32() % delay; - if (!mod_timer(&idev->mc_dad_timer, jiffies+tv+2)) - in6_dev_hold(idev); + if (in6_dev_hold_safe(idev)) { + if (mod_timer(&idev->mc_dad_timer, jiffies+tv+2)) + in6_dev_put(idev); + } } static void mld_dad_stop_timer(struct inet6_dev *idev) -- 2.33.8

2 2

[PATCH openEuler-1.0-LTS] ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD
by JiangJieHua 29 Aug '26

29 Aug '26

From: Linmao Li <lilinmao(a)kylinos.cn> mainline inclusion from mainline-v7.2-rc1 commit 627ac78f2741e2ebd2225e2e953b6964a8a9182f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18025 CVE: CVE-2026-74398 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released. Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing to workqueue") Signed-off-by: Linmao Li <lilinmao(a)kylinos.cn> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260513025509.3776405-1-lilinmao@kylinos.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv6/addrconf.c [Contextual differences between the branch and mainline required adaptation during patch application. The functional changes from the upstream commit are preserved.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/ipv6/addrconf.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 98a24b5e6f036..7b8dda47d3855 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -2020,16 +2020,18 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp) struct inet6_dev *idev = ifp->idev; struct net *net = dev_net(ifp->idev->dev); - if (addrconf_dad_end(ifp)) { + spin_lock_bh(&ifp->lock); + + if (ifp->state != INET6_IFADDR_STATE_DAD) { + spin_unlock_bh(&ifp->lock); in6_ifa_put(ifp); return; } + ifp->state = INET6_IFADDR_STATE_POSTDAD; net_info_ratelimited("%s: IPv6 duplicate address %pI6c used by %pM detected!\n", ifp->idev->dev->name, &ifp->addr, eth_hdr(skb)->h_source); - spin_lock_bh(&ifp->lock); - if (ifp->flags & IFA_F_STABLE_PRIVACY) { struct in6_addr new_addr; struct inet6_ifaddr *ifp2; @@ -2077,6 +2079,11 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp) in6_ifa_put(ifp2); lock_errdad: spin_lock_bh(&ifp->lock); + if (ifp->state != INET6_IFADDR_STATE_POSTDAD) { + spin_unlock_bh(&ifp->lock); + in6_ifa_put(ifp); + return; + } } errdad: -- 2.33.8

2 3

[PATCH openEuler-1.0-LTS] ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()
by JiangJieHua 29 Aug '26

29 Aug '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v7.2-rc3 commit 7b19c0f81ed1fdaec6bc522569be367199a9edf3 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/9704 CVE: CVE-2026-72323 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Zero Day Initiative <zdi-disclosures(a)trendmicro.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260705181756.963063-2-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/ipv4/igmp.c [For 4.19, get_random_u32_below() is not available, so igmp_ifc_start_timer() retains the original prandom_u32() % delay approach. The remaining refcount logic and the newly added in_dev_hold_safe() parts are consistent with upstream.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- include/linux/inetdevice.h | 5 +++++ net/ipv4/igmp.c | 14 +++++++++----- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h index a64f21a97369a..002f1de9a30f4 100644 --- a/include/linux/inetdevice.h +++ b/include/linux/inetdevice.h @@ -255,6 +255,11 @@ static inline void in_dev_put(struct in_device *idev) #define __in_dev_put(idev) refcount_dec(&(idev)->refcnt) #define in_dev_hold(idev) refcount_inc(&(idev)->refcnt) +static inline bool in_dev_hold_safe(struct in_device *idev) +{ + return refcount_inc_not_zero(&idev->refcnt); +} + #endif /* __KERNEL__ */ static __inline__ __be32 inet_make_mask(int logmask) diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c index c4b396968acd6..ed9ef8430c14f 100644 --- a/net/ipv4/igmp.c +++ b/net/ipv4/igmp.c @@ -237,16 +237,20 @@ static void igmp_gq_start_timer(struct in_device *in_dev) return; in_dev->mr_gq_running = 1; - if (!mod_timer(&in_dev->mr_gq_timer, exp)) - in_dev_hold(in_dev); + if (in_dev_hold_safe(in_dev)) { + if (mod_timer(&in_dev->mr_gq_timer, exp)) + in_dev_put(in_dev); + } } static void igmp_ifc_start_timer(struct in_device *in_dev, int delay) { - int tv = prandom_u32() % delay; + if (in_dev_hold_safe(in_dev)) { + int tv = prandom_u32() % (delay); - if (!mod_timer(&in_dev->mr_ifc_timer, jiffies+tv+2)) - in_dev_hold(in_dev); + if (mod_timer(&in_dev->mr_ifc_timer, jiffies + tv + 2)) + in_dev_put(in_dev); + } } static void igmp_mod_timer(struct ip_mc_list *im, int max_delay) -- 2.33.8

2 1

[PATCH openEuler-1.0-LTS] inet: frags: publish queues before arming timer
by JiangJieHua 29 Aug '26

29 Aug '26

From: Zhiling Zou <zhilinz(a)nebusec.ai> mainline inclusion from mainline-v7.2-rc7 commit 653d7ddf6cba867777a3d14c4f83ace008c5ad13 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18205 CVE: CVE-2026-74662 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference. Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units") Cc: stable(a)vger.kernel.org Reported-by: Vega <vega(a)nebusec.ai> Signed-off-by: Zhiling Zou <zhilinz(a)nebusec.ai> Signed-off-by: Ren Wei <enjou1224z(a)gmail.com> Link: https://patch.msgid.link/bf66785e7c0c139d7a1900e2f01faeeab344b960.178494884… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv4/inet_fragment.c [4.19 use struct netns_frags *nf (not struct fqdir *fqdir) and have no inet_frag_putn(); inet_frag_kill() takes a single argument. The conflict error path keeps the target's inet_frag_kill(q) + inet_frag_destroy(q) cleanup instead of upstream's inet_frag_putn(q, 2). The fix semantics are preserved: the queue is published into the rhashtable before the timer is armed, both under q->lock.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/ipv4/inet_fragment.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c index 5d004c3f4e2b0..4f2118c7f3db6 100644 --- a/net/ipv4/inet_fragment.c +++ b/net/ipv4/inet_fragment.c @@ -270,16 +270,19 @@ static struct inet_frag_queue *inet_frag_create(struct netns_frags *nf, *prev = ERR_PTR(-ENOMEM); return NULL; } - mod_timer(&q->timer, jiffies + nf->timeout); + spin_lock_bh(&q->lock); *prev = rhashtable_lookup_get_insert_key(&nf->rhashtable, &q->key, &q->node, f->rhash_params); if (*prev) { q->flags |= INET_FRAG_COMPLETE; + spin_unlock_bh(&q->lock); inet_frag_kill(q); inet_frag_destroy(q); return NULL; } + mod_timer(&q->timer, jiffies + nf->timeout); + spin_unlock_bh(&q->lock); return q; } -- 2.33.8

2 1

[PATCH openEuler-1.0-LTS] inet: frags: publish queues before arming timer
by JiangJieHua 29 Aug '26

29 Aug '26

From: Zhiling Zou <zhilinz(a)nebusec.ai> mainline inclusion from mainline-v7.2-rc7 commit 653d7ddf6cba867777a3d14c4f83ace008c5ad13 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18205 CVE: CVE-2026-74662 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference. Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units") Cc: stable(a)vger.kernel.org Reported-by: Vega <vega(a)nebusec.ai> Signed-off-by: Zhiling Zou <zhilinz(a)nebusec.ai> Signed-off-by: Ren Wei <enjou1224z(a)gmail.com> Link: https://patch.msgid.link/bf66785e7c0c139d7a1900e2f01faeeab344b960.178494884… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv4/inet_fragment.c [4.19 use struct netns_frags *nf (not struct fqdir *fqdir) and have no inet_frag_putn(); inet_frag_kill() takes a single argument. The conflict error path keeps the target's inet_frag_kill(q) + inet_frag_destroy(q) cleanup instead of upstream's inet_frag_putn(q, 2). The fix semantics are preserved: the queue is published into the rhashtable before the timer is armed, both under q->lock.] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/ipv4/inet_fragment.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c index 5d004c3f4e2b0..4f2118c7f3db6 100644 --- a/net/ipv4/inet_fragment.c +++ b/net/ipv4/inet_fragment.c @@ -270,16 +270,19 @@ static struct inet_frag_queue *inet_frag_create(struct netns_frags *nf, *prev = ERR_PTR(-ENOMEM); return NULL; } - mod_timer(&q->timer, jiffies + nf->timeout); + spin_lock_bh(&q->lock); *prev = rhashtable_lookup_get_insert_key(&nf->rhashtable, &q->key, &q->node, f->rhash_params); if (*prev) { q->flags |= INET_FRAG_COMPLETE; + spin_unlock_bh(&q->lock); inet_frag_kill(q); inet_frag_destroy(q); return NULL; } + mod_timer(&q->timer, jiffies + nf->timeout); + spin_unlock_bh(&q->lock); return q; } -- 2.33.8

2 1