- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed
by Pu Lehui 21 Sep '26

21 Sep '26

stable inclusion from stable-6.6.157 commit e26db0d636e4c24a6b16683ea95cf5077c64d74b category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------ [ Upstream commit 6655c409707ec8ce9ce0850ffe4fe02331fd4d9c ] A potential invalid storage access issue can occur after replacing a cgroup bpf prog. This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error. Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs on the same cgroup") Reported-by: Sashiko <sashiko-bot(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Emil Tsalapatis <emil(a)etsalapatis.com> Link: https://lore.kernel.org/bpf/20260803013934.4036646-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: kernel/bpf/cgroup.c [ctx conflicts] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cgroup.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index d72413d9b9bc..b51c37ff7ef4 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -651,8 +651,10 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *old_prog = NULL; struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {}; struct bpf_cgroup_storage *new_storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {}; + struct bpf_cgroup_storage *old_storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {}; struct bpf_prog *new_prog = prog ? : link->link.prog; enum cgroup_bpf_attach_type atype; + u32 old_flags, old_pl_flags; struct bpf_prog_list *pl; struct hlist_head *progs; int err; @@ -704,6 +706,8 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, if (pl) { old_prog = pl->prog; + old_pl_flags = pl->flags; + bpf_cgroup_storages_assign(old_storage, pl->storage); } else { struct hlist_node *last = NULL; @@ -726,6 +730,7 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, pl->prog = prog; pl->link = link; bpf_cgroup_storages_assign(pl->storage, storage); + old_flags = cgrp->bpf.flags[atype]; cgrp->bpf.flags[atype] = saved_flags; if (type == BPF_LSM_CGROUP) { @@ -756,12 +761,15 @@ static int __cgroup_bpf_attach(struct cgroup *cgrp, if (old_prog) { pl->prog = old_prog; pl->link = NULL; + pl->flags = old_pl_flags; + bpf_cgroup_storages_assign(pl->storage, old_storage); } bpf_cgroup_storages_free(new_storage); if (!old_prog) { hlist_del(&pl->node); kfree(pl); } + cgrp->bpf.flags[atype] = old_flags; return err; } -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: Compare iterator types during state pruning
by Pu Lehui 21 Sep '26

21 Sep '26

From: Ning Ding <dingning04(a)gmail.com> mainline inclusion from mainline-v7.3-rc1 commit 83608e303b95d07afba1c15da0b5d9e513c2f15a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19231 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states must not be equal, or the verifier can prune an unsafe path. Compare the pointer type for STACK_ITER slots. Fixes: dfab99df147b ("bpf: teach the verifier to enforce css_iter and task_iter in RCU CS") Signed-off-by: Ning Ding <dingning04(a)gmail.com> Acked-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://patch.msgid.link/20260811035955.132989-2-dingning04@gmail.com Signed-off-by: Eduard Zingerman <eddyz87(a)gmail.com> Conflicts: kernel/bpf/states.c kernel/bpf/verifier.c [ctx conflicts] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index acee64b8d7de..f73424707e60 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -16668,7 +16668,8 @@ static bool stacksafe(struct bpf_verifier_env *env, struct bpf_func_state *old, * infinite loop check triggering, see * iter_active_depths_differ() */ - if (old_reg->iter.btf != cur_reg->iter.btf || + if (old_reg->type != cur_reg->type || + old_reg->iter.btf != cur_reg->iter.btf || old_reg->iter.btf_id != cur_reg->iter.btf_id || old_reg->iter.state != cur_reg->iter.state || /* ignore {old_reg,cur_reg}->iter.depth, see above */ -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS V1] virtio_console: do not free control-out buffers on remove
by Yao Yiqi 21 Sep '26

21 Sep '26

From: Jia Jia <physicalmtea(a)gmail.com> mainline inclusion from mainline-v7.3-rc3 commit 894f98e73983f37354214a89a3a7fd35bf9e3072 category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): free_buf remove_vqs virtcons_remove unbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it. Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset") Signed-off-by: Jia Jia <physicalmtea(a)gmail.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Message-ID: <20260819021230.292696-1-physicalmtea(a)gmail.com> Signed-off-by: Yao Yiqi <yaoyiqi3(a)huawei.com> --- drivers/char/virtio_console.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index b6c966516946..6b926fd30a69 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1961,13 +1961,28 @@ static const struct file_operations portdev_fops = { static void remove_vqs(struct ports_device *portdev) { struct virtqueue *vq; + bool multiport = use_multiport(portdev); virtio_device_for_each_vq(portdev->vdev, vq) { struct port_buffer *buf; + unsigned int len; - flush_bufs(vq, true); - while ((buf = virtqueue_detach_unused_buf(vq))) - free_buf(buf, true); + /* + * c_ovq cookies are &portdev->cpkt, not port_buffer. + * Detach them but do not free_buf(). + */ + if (multiport && vq == portdev->c_ovq) { + spin_lock(&portdev->c_ovq_lock); + while (virtqueue_get_buf(vq, &len)) + ; + while (virtqueue_detach_unused_buf(vq)) + ; + spin_unlock(&portdev->c_ovq_lock); + } else { + flush_bufs(vq, true); + while ((buf = virtqueue_detach_unused_buf(vq))) + free_buf(buf, true); + } } portdev->vdev->config->del_vqs(portdev->vdev); kfree(portdev->in_vqs); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS v3 0/2] CVE-2026-89580
by Pu Lehui 21 Sep '26

21 Sep '26

Andrii Nakryiko (1): bpf: decouple stack_map_get_build_id_offset() from perf_callchain_entry Daniel Borkmann (1): bpf: Disable preemption in __bpf_get_stack kernel/bpf/stackmap.c | 55 +++++++++++++++++++++++++++++++------------ 1 file changed, 40 insertions(+), 15 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] bpf: Reject non-scalar bpf_loop iteration counts
by Pu Lehui 21 Sep '26

21 Sep '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/10028 -------------------------------- bpf_loop() declares its first param as ARG_ANYTHING, and after commit bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations") introduced precision tracking on R1 to bound loop iters, passing non-scalar value triggers "backtracing misuse" warning. The upstream commit c3fd8e5fd100 ("bpf: Reject non-scalar bpf_loop iteration counts") addressed this by introducing ARG_SCALAR into enum bpf_arg_type. However, it will breaks KABI. To avoid KABI breakage, let's validate that R1 is SCALAR_VALUE directly before doing precision tracking. Fixes: bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations") Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index bdeb3f5c72e7..acee64b8d7de 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -10359,6 +10359,10 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn err = check_bpf_snprintf_call(env, regs); break; case BPF_FUNC_loop: + if (regs[BPF_REG_1].type != SCALAR_VALUE) { + verbose(env, "R1 must be a scalar value for bpf_loop\n"); + return -EINVAL; + } update_loop_inline_state(env, meta.subprogno); /* Verifier relies on R1 value to determine if bpf_loop() iteration * is finished, thus mark it precise. -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/3] Fix CVE-2026-74668
by JiangJieHua 21 Sep '26

21 Sep '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 openEuler-1.0-LTS] ipv6: guard against possible NULL deref in __in6_dev_stats_get()
by JiangJieHua 21 Sep '26

21 Sep '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v7.2-rc1 commit 507541c2a8eeb76c02bd2511958f73a8cfa3e1bc category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18538 CVE: CVE-2026-80646 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dev_get_by_index_rcu() could return NULL if the original physical device is unregistered. Found by Sashiko. Fixes: e1ae5c2ea478 ("vrf: Increment Icmp6InMsgs on the original netdev") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Stephen Suryaputra <ssuryaextr(a)gmail.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260526145529.3587126-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- include/net/addrconf.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/net/addrconf.h b/include/net/addrconf.h index 10d270f004f0d..9d24316964b04 100644 --- a/include/net/addrconf.h +++ b/include/net/addrconf.h @@ -351,8 +351,11 @@ static inline struct inet6_dev *__in6_dev_get(const struct net_device *dev) static inline struct inet6_dev *__in6_dev_stats_get(const struct net_device *dev, const struct sk_buff *skb) { - if (netif_is_l3_master(dev)) + if (netif_is_l3_master(dev)) { dev = dev_get_by_index_rcu(dev_net(dev), inet6_iif(skb)); + if (!dev) + return NULL; + } return __in6_dev_get(dev); } -- 2.33.8

2 1

[PATCH openEuler-1.0-LTS] packet: synchronize pressure clearing with ring reconfiguration
by JiangJieHua 21 Sep '26

21 Sep '26

From: Zihan Xi <zihanx(a)nebusec.ai> mainline inclusion from mainline-v7.2-rc7 commit 1a35da325cac4d5bcad76a2aa943408a6f1d9000 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18207 CVE: CVE-2026-74666 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly. Fixes: 2ccdbaa6d55b ("packet: rollover lock contention avoidance") Cc: stable(a)vger.kernel.org Reported-by: Vega <vega(a)nebusec.ai> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi <zihanx(a)nebusec.ai> Link: https://patch.msgid.link/f90b5688311fa278d1361ea8c6be0bf25967d591.178524744… Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/packet/af_packet.c [Context differences are due to the following patches not being merged: 9bb6cd652454 ("net/packet: introduce packet_rcv_try_clear_pressure() helper") 791a3e9f1a86 ("net/packet: convert po->pressure to an atomic flag")] Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/packet/af_packet.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index f8f8728cff536..ae1e16d2a9d5d 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -4431,14 +4431,14 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u, rb->frame_max = (req->tp_frame_nr - 1); rb->head = 0; rb->frame_size = req->tp_frame_size; + po->prot_hook.func = (po->rx_ring.pg_vec) ? + tpacket_rcv : packet_rcv; spin_unlock_bh(&rb_queue->lock); swap(rb->pg_vec_order, order); swap(rb->pg_vec_len, req->tp_block_nr); rb->pg_vec_pages = req->tp_block_size/PAGE_SIZE; - po->prot_hook.func = (po->rx_ring.pg_vec) ? - tpacket_rcv : packet_rcv; skb_queue_purge(rb_queue); if (atomic_long_read(&po->mapped)) pr_err("packet_mmap: vma is busy: %ld\n", -- 2.33.8

2 1

[PATCH openEuler-1.0-LTS] ipv6: prevent in6_dev_get() from resurrecting inet6_dev
by JiangJieHua 21 Sep '26

21 Sep '26

From: Kyle Zeng <kylebot(a)openai.com> mainline inclusion from mainline-v7.2-rc7 commit 0e243671bc7b8eaf00f83dd2f4367436dc0cff98 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18316 CVE: CVE-2026-74630 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed. Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller. An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000: refcount_t: addition on 0; use-after-free. ip6_mc_source+0xef4/0x17e0 It was followed by the corresponding reference underflow in ip6_mc_source(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends: BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219 Bug found and triaged by OpenAI Security Research and validated by Trail of Bits. Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.") Cc: stable(a)vger.kernel.org Signed-off-by: Kyle Zeng <kylebot(a)openai.com> Co-developed-by: David Lee <david.lee(a)trailofbits.com> Signed-off-by: David Lee <david.lee(a)trailofbits.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260803122758.666112-1-david.lee@trailofbits.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- include/net/addrconf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/net/addrconf.h b/include/net/addrconf.h index 10d270f004f0d..de1e3dd0c26b5 100644 --- a/include/net/addrconf.h +++ b/include/net/addrconf.h @@ -384,8 +384,8 @@ static inline struct inet6_dev *in6_dev_get(const struct net_device *dev) rcu_read_lock(); idev = rcu_dereference(dev->ip6_ptr); - if (idev) - refcount_inc(&idev->refcnt); + if (idev && !refcount_inc_not_zero(&idev->refcnt)) + idev = NULL; rcu_read_unlock(); return idev; } -- 2.33.8

2 1

[PATCH openEuler-1.0-LTS] ipv6: fix Route Information option length validation
by JiangJieHua 21 Sep '26

21 Sep '26

From: Yuejie Shi <syjcnss(a)gmail.com> mainline inclusion from mainline-v7.2-rc7 commit d1ad8fb2ac6a1afb71dc22d9ae8efb4dda96c824 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18174 CVE: CVE-2026-74598 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow. Fixes: 70ceb4f53929 ("[IPV6]: ROUTE: Add experimental support for Route Information Option in RA (RFC4191).") Cc: stable(a)vger.kernel.org Signed-off-by: Yuejie Shi <syjcnss(a)gmail.com> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Link: https://patch.msgid.link/20260730035310.74584-1-syjcnss@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: JiangJieHua <jiangjiehua1(a)huawei.com> --- net/ipv6/route.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 907a5e5078199..e806ddc33c259 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -821,13 +821,13 @@ int rt6_route_rcv(struct net_device *dev, u8 *opt, int len, } else if (rinfo->prefix_len > 128) { return -EINVAL; } else if (rinfo->prefix_len > 64) { - if (rinfo->length < 2) { + /* RFC 4191: Length MUST be 3 when Prefix Length > 64 */ + if (rinfo->length < 3) return -EINVAL; - } } else if (rinfo->prefix_len > 0) { - if (rinfo->length < 1) { + /* RFC 4191: Length MUST be 2 or 3 when Prefix Length > 0 */ + if (rinfo->length < 2) return -EINVAL; - } } pref = rinfo->route_pref; -- 2.33.8

2 1