- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 1/1] KVM: arm64: vgic-v3: Restrict ICH_AP1Rn_EL2 accesses to 64-bit only with vNMI
by Jinqian Yang 31 Aug '26

31 Aug '26

ICH_AP1Rn_EL2 is 64-bit only when vNMI is in use, with the NMI priority in ICH_AP1R0_EL2[63:32]; otherwise the upper bits are RES0. Gate the save/restore access width on vgic_v3_vcpu_has_vnmi() which checks both vgic.has_nmi and ID_AA64PFR1_EL1.NMI, so that the NMI priority is preserved across context switch only when vNMI is actually enabled for the guest. Also drop the early assignment of kvm->arch.pfr1_nmi in kvm_arch_init_vm(). Without it vNMI is no longer enabled by default at VM creation on hosts with FEAT_NMI; instead the VMM must explicitly set ID_AA64PFR1_EL1.NMI via SET_ONE_REG to enable vNMI for the guest. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- arch/arm64/include/asm/kvm_hyp.h | 1 + arch/arm64/kvm/arm.c | 3 -- arch/arm64/kvm/hyp/vgic-v3-sr.c | 55 +++++++++++++++++++++++++++----- 3 files changed, 48 insertions(+), 11 deletions(-) diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h index 127ad280e68b..c4121bf0aadc 100644 --- a/arch/arm64/include/asm/kvm_hyp.h +++ b/arch/arm64/include/asm/kvm_hyp.h @@ -82,6 +82,7 @@ void __vgic_v3_activate_traps(struct vgic_v3_cpu_if *cpu_if); void __vgic_v3_deactivate_traps(struct vgic_v3_cpu_if *cpu_if); void __vgic_v3_save_aprs(struct vgic_v3_cpu_if *cpu_if); void __vgic_v3_restore_aprs(struct vgic_v3_cpu_if *cpu_if); +bool vgic_v3_vcpu_has_vnmi(struct kvm_vcpu *vcpu); int __vgic_v3_perform_cpuif_access(struct kvm_vcpu *vcpu); #ifdef __KVM_NVHE_HYPERVISOR__ diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 2b560eba3e0b..9a4be08730da 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -381,9 +381,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) /* The maximum number of VCPUs is limited by the host's GIC model */ kvm->max_vcpus = kvm_arm_default_max_vcpus(); - if (cpus_have_const_cap(ARM64_HAS_NMI) && !static_branch_unlikely(&vgic_v3_cpuif_trap)) - kvm->arch.pfr1_nmi = ID_AA64PFR1_EL1_NMI_IMP; - kvm_arm_init_hypercalls(kvm); if (!kvm_is_realm(kvm)) diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c index 7a9e132f68db..ab406332762e 100644 --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c @@ -335,10 +335,40 @@ void __vgic_v3_deactivate_traps(struct vgic_v3_cpu_if *cpu_if) write_gicreg(0, ICH_HCR_EL2); } +static struct kvm_vcpu *vgic_v3_cpu_if_to_vcpu(struct vgic_v3_cpu_if *cpu_if) +{ + struct vgic_cpu *vgic_cpu = container_of(cpu_if, struct vgic_cpu, vgic_v3); + + return container_of(vgic_cpu, struct kvm_vcpu, arch.vgic_cpu); +} + +/* + * vNMI is only usable if the guest has selected NMI support + * (vgic.has_nmi) and the vcpu has FEAT_NMI (pfr1_nmi). + * + * This drives the width of the ICH_AP1Rn_EL2 accesses: with vNMI the + * registers are 64bit (the NMI priority lives in ICH_AP1R0_EL2[63]), + * without it only the low 32 bits are valid. + */ +bool vgic_v3_vcpu_has_vnmi(struct kvm_vcpu *vcpu) +{ + struct kvm *kvm = kern_hyp_va(vcpu->kvm); + + return kvm->arch.vgic.has_nmi && + kvm->arch.pfr1_nmi == ID_AA64PFR1_EL1_NMI_IMP; +} + void __vgic_v3_save_aprs(struct vgic_v3_cpu_if *cpu_if) { u64 val; u32 nr_pre_bits; + /* + * ICH_AP1Rn_EL2 are only 64bit when the vcpu has vNMI: the NMI + * priority is encoded in ICH_AP1R0_EL2[63]. Without vNMI, the + * upper bits are RES0 and only the low 32 bits must be + * preserved. + */ + bool vnmi = vgic_v3_vcpu_has_vnmi(vgic_v3_cpu_if_to_vcpu(cpu_if)); val = read_gicreg(ICH_VTR_EL2); nr_pre_bits = vtr_to_nr_pre_bits(val); @@ -357,14 +387,18 @@ void __vgic_v3_save_aprs(struct vgic_v3_cpu_if *cpu_if) switch (nr_pre_bits) { case 7: - cpu_if->vgic_ap1r[3] = __vgic_v3_read_ap1rn(3); - cpu_if->vgic_ap1r[2] = __vgic_v3_read_ap1rn(2); + cpu_if->vgic_ap1r[3] = vnmi ? __vgic_v3_read_ap1rn(3) + : (u32)__vgic_v3_read_ap1rn(3); + cpu_if->vgic_ap1r[2] = vnmi ? __vgic_v3_read_ap1rn(2) + : (u32)__vgic_v3_read_ap1rn(2); fallthrough; case 6: - cpu_if->vgic_ap1r[1] = __vgic_v3_read_ap1rn(1); + cpu_if->vgic_ap1r[1] = vnmi ? __vgic_v3_read_ap1rn(1) + : (u32)__vgic_v3_read_ap1rn(1); fallthrough; default: - cpu_if->vgic_ap1r[0] = __vgic_v3_read_ap1rn(0); + cpu_if->vgic_ap1r[0] = vnmi ? __vgic_v3_read_ap1rn(0) + : (u32)__vgic_v3_read_ap1rn(0); } } @@ -372,6 +406,7 @@ void __vgic_v3_restore_aprs(struct vgic_v3_cpu_if *cpu_if) { u64 val; u32 nr_pre_bits; + bool vnmi = vgic_v3_vcpu_has_vnmi(vgic_v3_cpu_if_to_vcpu(cpu_if)); val = read_gicreg(ICH_VTR_EL2); nr_pre_bits = vtr_to_nr_pre_bits(val); @@ -390,14 +425,18 @@ void __vgic_v3_restore_aprs(struct vgic_v3_cpu_if *cpu_if) switch (nr_pre_bits) { case 7: - __vgic_v3_write_ap1rn(cpu_if->vgic_ap1r[3], 3); - __vgic_v3_write_ap1rn(cpu_if->vgic_ap1r[2], 2); + __vgic_v3_write_ap1rn(vnmi ? cpu_if->vgic_ap1r[3] + : (u32)cpu_if->vgic_ap1r[3], 3); + __vgic_v3_write_ap1rn(vnmi ? cpu_if->vgic_ap1r[2] + : (u32)cpu_if->vgic_ap1r[2], 2); fallthrough; case 6: - __vgic_v3_write_ap1rn(cpu_if->vgic_ap1r[1], 1); + __vgic_v3_write_ap1rn(vnmi ? cpu_if->vgic_ap1r[1] + : (u32)cpu_if->vgic_ap1r[1], 1); fallthrough; default: - __vgic_v3_write_ap1rn(cpu_if->vgic_ap1r[0], 0); + __vgic_v3_write_ap1rn(vnmi ? cpu_if->vgic_ap1r[0] + : (u32)cpu_if->vgic_ap1r[0], 0); } } -- 2.33.0

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 | 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