- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] hwrng: virtio: clamp device-reported used.len at copy_data()
by Chen Jinghuang 03 Aug '26

03 Aug '26

From: Michael Bommarito <michael.bommarito(a)gmail.com> mainline inclusion from mainline-v7.2-rc1 commit e3046eeada299f917a8ad883af4434bfb86556b1 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16747 CVE: CVE-2026-64456 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request. Fixes: f7f510ec1957 ("virtio: An entropy device, as suggested by hpa.") Cc: stable(a)vger.kernel.org Suggested-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Message-ID: <20260531142251.2792061-1-michael.bommarito(a)gmail.com> Conflicts: drivers/char/hw_random/virtio-rng.c [context conflicts] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/char/hw_random/virtio-rng.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c index 58884d875201..f4b695b33277 100644 --- a/drivers/char/hw_random/virtio-rng.c +++ b/drivers/char/hw_random/virtio-rng.c @@ -20,6 +20,7 @@ #include <asm/barrier.h> #include <linux/err.h> #include <linux/hw_random.h> +#include <linux/nospec.h> #include <linux/scatterlist.h> #include <linux/spinlock.h> #include <linux/virtio.h> @@ -78,8 +79,26 @@ static void request_entropy(struct virtrng_info *vi) static unsigned int copy_data(struct virtrng_info *vi, void *buf, unsigned int size) { - size = min_t(unsigned int, size, vi->data_avail); - memcpy(buf, vi->data + vi->data_idx, size); + unsigned int idx, avail; + + /* + * vi->data_avail was set from the device-reported used.len and + * vi->data_idx was advanced by previous copy_data() calls. A + * malicious or buggy virtio-rng backend can drive either past + * sizeof(vi->data). Clamp at point of use and harden the index + * with array_index_nospec() so the memcpy() below cannot be + * steered into adjacent slab memory, including under + * speculation. + */ + avail = min_t(unsigned int, vi->data_avail, sizeof(vi->data)); + if (vi->data_idx >= avail) { + vi->data_avail = 0; + request_entropy(vi); + return 0; + } + size = min_t(unsigned int, size, avail - vi->data_idx); + idx = array_index_nospec(vi->data_idx, sizeof(vi->data)); + memcpy(buf, vi->data + idx, size); vi->data_idx += size; vi->data_avail -= size; if (vi->data_avail == 0) -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] CVE-2026-64560
by Jinjie Ruan 03 Aug '26

03 Aug '26

CVE-2026-64560. Peter Zijlstra (1): locking: Introduce __cleanup() based infrastructure Thomas Gleixner (1): posix-cpu-timers: Prevent UAF caused by non-leader exec() race drivers/dma/ioat/dma.c | 12 +- include/linux/cleanup.h | 171 +++++++++++++++++++++++++ include/linux/compiler-clang.h | 9 ++ include/linux/compiler_attributes.h | 6 + include/linux/device.h | 7 ++ include/linux/file.h | 6 + include/linux/irqflags.h | 7 ++ include/linux/mutex.h | 4 + include/linux/percpu.h | 4 + include/linux/preempt.h | 5 + include/linux/rcupdate.h | 3 + include/linux/rwsem.h | 9 ++ include/linux/sched/task.h | 2 + include/linux/slab.h | 4 +- include/linux/spinlock.h | 32 +++++ include/linux/srcu.h | 5 + kernel/exit.c | 8 +- kernel/signal.c | 10 +- kernel/time/posix-cpu-timers.c | 185 ++++++++++++++++++---------- scripts/checkpatch.pl | 2 +- 20 files changed, 417 insertions(+), 74 deletions(-) create mode 100644 include/linux/cleanup.h -- 2.34.1

2 3

[PATCH OLK-6.6 v3 0/5] bpf mainline
by Pu Lehui 03 Aug '26

03 Aug '26

David Windsor (1): bpf: Reject sleepable BPF_LSM_CGROUP programs at load time Jiri Olsa (1): bpf: Guard __get_user acesss with access_ok for uprobe_multi data Kaitao Cheng (1): bpf: Clear rb node linkage when freeing bpf_rb_root Xu Kuohai (2): bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno bpf: Add validation for bpf_set_retval argument include/linux/bpf_lsm.h | 6 ++++ kernel/bpf/bpf_lsm.c | 20 ++++++++++++ kernel/bpf/cgroup.c | 47 ++++++++++++++++++++-------- kernel/bpf/helpers.c | 11 +++++-- kernel/bpf/verifier.c | 67 +++++++++++++++++++++++++++++++++++++--- kernel/trace/bpf_trace.c | 11 +++++++ 6 files changed, 143 insertions(+), 19 deletions(-) -- 2.34.1

2 6

[PATCH OLK-6.6] firmware_loader: fix device reference leak in firmware_upload_register()
by Zhang Yuwei 03 Aug '26

03 Aug '26

From: Guangshuo Li <lgs201920130244(a)gmail.com> stable inclusion from stable-v6.6.145 commit 46d403da376a8b7c1187193294953816e1a8d7fe category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16671 CVE: CVE-2026-64376 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 896df22ee57648b0c505bd76ddbc6b2341834696 upstream. firmware_upload_register() -> fw_create_instance() -> device_initialize() After fw_create_instance() succeeds, the lifetime of the embedded struct device is expected to be managed through the device core reference counting, since fw_create_instance() has already called device_initialize(). In firmware_upload_register(), if alloc_lookup_fw_priv() fails after fw_create_instance() succeeds, the code reaches free_fw_sysfs and frees fw_sysfs directly instead of releasing the device reference with put_device(). This may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device(fw_dev) in the failure path and letting fw_dev_release() handle the final cleanup, instead of freeing the instance directly from the error path. Fixes: 97730bbb242c ("firmware_loader: Add firmware-upload support") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> Link: https://patch.msgid.link/20260505091231.607089-1-lgs201920130244@gmail.com Signed-off-by: Danilo Krummrich <dakr(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Signed-off-by: Zhang Yuwei <zhangyuwei20(a)huawei.com> --- drivers/base/firmware_loader/sysfs_upload.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/base/firmware_loader/sysfs_upload.c b/drivers/base/firmware_loader/sysfs_upload.c index a0af8f5f13d8..54a1abae3948 100644 --- a/drivers/base/firmware_loader/sysfs_upload.c +++ b/drivers/base/firmware_loader/sysfs_upload.c @@ -340,7 +340,6 @@ firmware_upload_register(struct module *module, struct device *parent, goto free_fw_upload_priv; } fw_upload->priv = fw_sysfs; - fw_sysfs->fw_upload_priv = fw_upload_priv; fw_dev = &fw_sysfs->dev; ret = alloc_lookup_fw_priv(name, &fw_cache, &fw_priv, NULL, 0, 0, @@ -348,10 +347,12 @@ firmware_upload_register(struct module *module, struct device *parent, if (ret != 0) { if (ret > 0) ret = -EINVAL; - goto free_fw_sysfs; + put_device(fw_dev); + goto free_fw_upload_priv; } fw_priv->is_paged_buf = true; fw_sysfs->fw_priv = fw_priv; + fw_sysfs->fw_upload_priv = fw_upload_priv; ret = device_add(fw_dev); if (ret) { @@ -362,9 +363,6 @@ firmware_upload_register(struct module *module, struct device *parent, return fw_upload; -free_fw_sysfs: - kfree(fw_sysfs); - free_fw_upload_priv: kfree(fw_upload_priv); -- 2.22.0

2 1

[PATCH OLK-6.6] firmware_loader: fix device reference leak in firmware_upload_register()
by Zhang Yuwei 03 Aug '26

03 Aug '26

From: Guangshuo Li <lgs201920130244(a)gmail.com> stable inclusion from stable-v6.6.145 commit 46d403da376a8b7c1187193294953816e1a8d7fe category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16671 CVE: CVE-2026-64376 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 896df22ee57648b0c505bd76ddbc6b2341834696 upstream. firmware_upload_register() -> fw_create_instance() -> device_initialize() After fw_create_instance() succeeds, the lifetime of the embedded struct device is expected to be managed through the device core reference counting, since fw_create_instance() has already called device_initialize(). In firmware_upload_register(), if alloc_lookup_fw_priv() fails after fw_create_instance() succeeds, the code reaches free_fw_sysfs and frees fw_sysfs directly instead of releasing the device reference with put_device(). This may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device(fw_dev) in the failure path and letting fw_dev_release() handle the final cleanup, instead of freeing the instance directly from the error path. Fixes: 97730bbb242c ("firmware_loader: Add firmware-upload support") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> Link: https://patch.msgid.link/20260505091231.607089-1-lgs201920130244@gmail.com Signed-off-by: Danilo Krummrich <dakr(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> --- drivers/base/firmware_loader/sysfs_upload.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/base/firmware_loader/sysfs_upload.c b/drivers/base/firmware_loader/sysfs_upload.c index a0af8f5f13d8..54a1abae3948 100644 --- a/drivers/base/firmware_loader/sysfs_upload.c +++ b/drivers/base/firmware_loader/sysfs_upload.c @@ -340,7 +340,6 @@ firmware_upload_register(struct module *module, struct device *parent, goto free_fw_upload_priv; } fw_upload->priv = fw_sysfs; - fw_sysfs->fw_upload_priv = fw_upload_priv; fw_dev = &fw_sysfs->dev; ret = alloc_lookup_fw_priv(name, &fw_cache, &fw_priv, NULL, 0, 0, @@ -348,10 +347,12 @@ firmware_upload_register(struct module *module, struct device *parent, if (ret != 0) { if (ret > 0) ret = -EINVAL; - goto free_fw_sysfs; + put_device(fw_dev); + goto free_fw_upload_priv; } fw_priv->is_paged_buf = true; fw_sysfs->fw_priv = fw_priv; + fw_sysfs->fw_upload_priv = fw_upload_priv; ret = device_add(fw_dev); if (ret) { @@ -362,9 +363,6 @@ firmware_upload_register(struct module *module, struct device *parent, return fw_upload; -free_fw_sysfs: - kfree(fw_sysfs); - free_fw_upload_priv: kfree(fw_upload_priv); -- 2.22.0

2 1

[PATCH OLK-6.6 v2] bpf: Support for hardening against JIT spraying
by Pu Lehui 02 Aug '26

02 Aug '26

From: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> stable inclusion from stable-v6.6.145 commit 6e52c240c43a601b681e3a4e58fc5685114d4726 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9711 CVE: CVE-2026-64508 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 96cce16e26dd02a8678f1e87f88a4b5cdb63b995 upstream. The BPF JIT allocator packs many small programs into larger executable allocations and reuses space within those allocations as programs are loaded and freed. When fresh code is written into space that a previous program occupied, an indirect jump into the new program can reuse a branch prediction left behind by the old one. Flush the indirect branch predictors before reusing JIT memory so that indirect jumps into a newly written program don't reuse predictions from an old program that occupied the same space. Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush static call for flushing the branch predictors on JIT memory reuse. Architectures that need a flush, can update it to a predictor flush function. By default, its a NOP and does not emit any CALL. Allocations larger than a pack are not covered by this flush. That is safe because cBPF programs (the unprivileged attack surface) are bounded well below a pack size. Issue a warning if this assumption is ever violated while the flush is active. Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- include/linux/filter.h | 10 ++++++++++ kernel/bpf/core.c | 19 +++++++++++++++++++ 2 files changed, 29 insertions(+) diff --git a/include/linux/filter.h b/include/linux/filter.h index 2136040bbaea..cb693a4c54c4 100644 --- a/include/linux/filter.h +++ b/include/linux/filter.h @@ -22,6 +22,7 @@ #include <linux/vmalloc.h> #include <linux/sockptr.h> #include <crypto/sha1.h> +#include <linux/static_call.h> #include <linux/u64_stats_sync.h> #include <net/sch_generic.h> @@ -1039,6 +1040,15 @@ extern long bpf_jit_limit_max; typedef void (*bpf_jit_fill_hole_t)(void *area, unsigned int size); +/* + * Flush the indirect branch predictors before reusing JIT memory, so that + * indirect jumps into a newly written program don't reuse predictions left + * behind by an old program that occupied the same space. + */ +void bpf_arch_pred_flush(void); +DECLARE_STATIC_CALL(bpf_arch_pred_flush, bpf_arch_pred_flush); +DECLARE_STATIC_KEY_FALSE(bpf_pred_flush_enabled); + void bpf_jit_fill_hole_with_zero(void *area, unsigned int size); struct bpf_binary_header * diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index 7f9a5f46226a..f53f401ae72b 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -37,6 +37,7 @@ #include <linux/nospec.h> #include <linux/bpf_mem_alloc.h> #include <linux/memcontrol.h> +#include <linux/static_call.h> #include <asm/barrier.h> #include <asm/unaligned.h> @@ -884,6 +885,15 @@ void bpf_jit_fill_hole_with_zero(void *area, unsigned int size) memset(area, 0, size); } +DEFINE_STATIC_CALL_NULL(bpf_arch_pred_flush, bpf_arch_pred_flush); + +/* + * Enabled once bpf_arch_pred_flush points at a real flush routine. Lets the + * pack allocator test "is a predictor flush wired up at all" with a cheap + * static branch instead of repeatedly querying the static call target. + */ +DEFINE_STATIC_KEY_FALSE(bpf_pred_flush_enabled); + #define BPF_PROG_SIZE_TO_NBITS(size) (round_up(size, BPF_PROG_CHUNK_SIZE) / BPF_PROG_CHUNK_SIZE) static DEFINE_MUTEX(pack_mutex); @@ -943,6 +953,14 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns) mutex_lock(&pack_mutex); if (size > BPF_PROG_PACK_SIZE) { + /* + * Allocations larger than a pack get their own pages, and + * predictors are not flushed for such allocation. This is only + * safe because cBPF programs (the unprivileged attack surface) + * are bounded well below a pack size. + */ + if (static_branch_unlikely(&bpf_pred_flush_enabled)) + pr_warn_once("BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\n"); size = round_up(size, PAGE_SIZE); ptr = bpf_jit_alloc_exec(size); if (ptr) { @@ -973,6 +991,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns) pos = 0; found_free_area: + static_call_cond(bpf_arch_pred_flush)(); bitmap_set(pack->bitmap, pos, nbits); ptr = (void *)(pack->ptr) + (pos << BPF_PROG_CHUNK_SHIFT); -- 2.34.1

2 1

[PATCH OLK-5.10] posix-cpu-timers: Prevent UAF caused by non-leader exec() race
by Jinjie Ruan 31 Jul '26

31 Jul '26

From: Thomas Gleixner <tglx(a)kernel.org> stable inclusion from stable-v5.10.262 commit 67aa823e3e8c229c6d374df79c804f6721cb83b6 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16862 CVE: CVE-2026-64560 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 920f893f735e92ba3a1cd9256899a186b161928d upstream. Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is "harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary workaround for that in 2010 which survived about 10 years. The fix for the workaround changed the task pointer to a pid pointer, but failed to see the subtle race described above. So the Fixes tag picks that commit, which seems to be halfways accurate. Thanks to Frederic Weissbecker, Oleg Nesterov and Peter Zijlstra for review, feedback and suggestions and to Wongi and Jungwoo for the excellent bug report and analysis! Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") Reported-by: Wongi Lee <qw3rtyp0(a)gmail.com> Reported-by: Jungwoo Lee <jwlee2217(a)gmail.com> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Reviewed-by: Oleg Nesterov <oleg(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: kernel/time/posix-cpu-timers.c [ context conflicts. ] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/exit.c | 8 +- kernel/signal.c | 10 +- kernel/time/posix-cpu-timers.c | 185 +++++++++++++++++++++------------ 3 files changed, 137 insertions(+), 66 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index 86b083f5fd60..3427e9514968 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -154,7 +154,13 @@ static void __exit_signal(struct task_struct *tsk) * doing sigqueue_free() if we have SIGQUEUE_PREALLOC signals. */ flush_sigqueue(&tsk->pending); - tsk->sighand = NULL; + + /* + * Ensure that all preceeding state is visible. Pairs with + * the smp_acquire__after_ctrl_dep() in the sighand == NULL + * path of lock_task_sighand(). + */ + smp_store_release(&tsk->sighand, NULL); spin_unlock(&sighand->siglock); __cleanup_sighand(sighand); diff --git a/kernel/signal.c b/kernel/signal.c index 91d177e1023d..77e8c2eaab70 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1382,8 +1382,16 @@ struct sighand_struct *__lock_task_sighand(struct task_struct *tsk, rcu_read_lock(); for (;;) { sighand = rcu_dereference(tsk->sighand); - if (unlikely(sighand == NULL)) + if (unlikely(sighand == NULL)) { + /* + * Pairs with the smp_store_release() in + * __exit_signal(). It ensures that all state + * modifications to the task preceeding the store are + * visible to the callers of lock_task_sighand(). + */ + smp_acquire__after_ctrl_dep(); break; + } /* * This sighand can be already freed and even reused, but diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c index 3e08c8991833..1a2f6ef4846e 100644 --- a/kernel/time/posix-cpu-timers.c +++ b/kernel/time/posix-cpu-timers.c @@ -405,6 +405,110 @@ static int posix_cpu_timer_create(struct k_itimer *new_timer) return 0; } +/* + * Lookup the task via timer->it.cpu.pid and attempt to lock the task's sighand. + * + * This can race with the reaping of the task: + * + * CPU0 CPU1 + * + * // Finds task + * p = pid_task(pid, pid_type); __exit_signal(p) + * lock(p, sighand); + * posix_cpu_timers*_exit(); + * sighand = lock_task_sighand(p); unhash_task(p); + * p->sighand = NULL; + * unlock(sighand); + * + * In this case sighand is NULL, which means the task and the associated timer + * queue cannot be longer accessed safely. + * + * __exit_signal() invokes posix_cpu_timers_exit() and if the thread group is + * dead it also invokes posix_cpu_timers_group_exit(). These functions delete + * all pending timers from the related timer queues. The POSIX timers (k_itimer) + * themself are still accessible, but not longer connected to the task. + * + * exec() works slightly differently. The task which exec()'s terminates all + * other threads in the thread group and runs __exit_signal() on them. As the + * thread group is not dead they only clean up the per task timers via + * posix_cpu_timers_exit(). + * + * As the TGID on exec() stays the same per process timers stay queued, if they + * are armed. This works without a problem when exec() is done by the thread + * group leader. If a non-leader thread exec()'s this can end up in the + * following scenario: + * + * CPU0 CPU1 + * // Returns old leader + * p = pid_task(pid, pid_type); de_thread() + * switch_leader() + * release_task(old leader) + * __exit_signal() + * old_leader->sighand = NULL; + * // Returns NULL + * sighand = lock_task_sighand(p) + * + * That's problematic for several functions: + * + * - posix_cpu_timer_del(): If the timer is still enqueued on the task the + * underlying k_itimer will be freed which results in a UAF in + * run_posix_cpu_timers() or on timerqueue related add/delete operations. + * If the timer is not enqueued, the failure is harmless + * + * - posix_cpu_timer_set(): Independent of the enqueued state that results in a + * transient failure which is user space visible (-ESRCH) for regular posix + * timers. But for the use case in do_cpu_nanosleep() it's the same UAF + * problem just that the timer is allocated on the stack. + * + * - posix_cpu_timer_rearm(): Timer is not enqueued at that point, but this + * silently ignores the rearm request, which is a functional problem as the + * timer wont expire anymore. + */ +static struct task_struct *timer_lock_sighand(struct k_itimer *timer, unsigned long *flags) +{ + enum pid_type type = clock_pid_type(timer->it_clock); + struct cpu_timer *ctmr = &timer->it.cpu; + + guard(rcu)(); + + for (;;) { + struct task_struct *t = pid_task(timer->it.cpu.pid, type); + + /* Fail if the task cannot be found. */ + if (!t) + break; + + /* Try to lock the task's sighand */ + if (lock_task_sighand(t, flags)) + return t; + + /* + * The next PID lookup might either fail or return the new + * leader. This is correct for both exit() and exec(). + */ + } + + /* + * If the timer is still enqueued, warn. There is nothing safe to do + * here as there might be two timers in there which are removed in + * parallel and that will cause more damage than good. This should never + * happen! + * + * Ensure that the stores to the timer and timerqueue are visible: + * + * __exit_signal() + * posix_cpu_timers*_exit() + * write_seqlock(seqlock) + * smp_wmb(); <------- + * __unhash_process() | !pid_task() + * ----> smp_rmb(); + * WARN_ON_ONCE(...) + */ + smp_rmb(); + WARN_ON_ONCE(ctmr->head || timerqueue_node_queued(&ctmr->node)); + return NULL; +} + /* * Clean up a CPU-clock timer that is about to be destroyed. * This is called from timer deletion with the timer already locked. @@ -414,28 +518,13 @@ static int posix_cpu_timer_create(struct k_itimer *new_timer) static int posix_cpu_timer_del(struct k_itimer *timer) { struct cpu_timer *ctmr = &timer->it.cpu; - struct sighand_struct *sighand; struct task_struct *p; unsigned long flags; int ret = 0; - rcu_read_lock(); - p = cpu_timer_task_rcu(timer); - if (!p) - goto out; + p = timer_lock_sighand(timer, &flags); - /* - * Protect against sighand release/switch in exit/exec and process/ - * thread timer list entry concurrent read/writes. - */ - sighand = lock_task_sighand(p, &flags); - if (unlikely(sighand == NULL)) { - /* - * This raced with the reaping of the task. The exit cleanup - * should have removed this timer from the timer queue. - */ - WARN_ON_ONCE(ctmr->head || timerqueue_node_queued(&ctmr->node)); - } else { + if (likely(p)) { if (timer->it.cpu.firing) ret = TIMER_RETRY; else @@ -444,8 +533,6 @@ static int posix_cpu_timer_del(struct k_itimer *timer) unlock_task_sighand(p, &flags); } -out: - rcu_read_unlock(); if (!ret) put_pid(ctmr->pid); @@ -575,37 +662,19 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, clockid_t clkid = CPUCLOCK_WHICH(timer->it_clock); u64 old_expires, new_expires, old_incr, val; struct cpu_timer *ctmr = &timer->it.cpu; - struct sighand_struct *sighand; struct task_struct *p; unsigned long flags; int ret = 0; - rcu_read_lock(); - p = cpu_timer_task_rcu(timer); - if (!p) { - /* - * If p has just been reaped, we can no - * longer get any information about it at all. - */ - rcu_read_unlock(); - return -ESRCH; - } - - new_expires = timespec64_to_ns(&new->it_value); - + p = timer_lock_sighand(timer, &flags); /* - * Protect against sighand release/switch in exit/exec and p->cpu_timers - * and p->signal->cpu_timers read/write in arm_timer() + * If p has just been reaped, we can no longer get any information about + * it at all. */ - sighand = lock_task_sighand(p, &flags); - /* - * If p has just been reaped, we can no - * longer get any information about it at all. - */ - if (unlikely(sighand == NULL)) { - rcu_read_unlock(); + if (!p) return -ESRCH; - } + + new_expires = timespec64_to_ns(&new->it_value); /* * Disarm any old timer after extracting its expiry time. @@ -655,6 +724,8 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, old->it_value.tv_sec = 0; } } + + old->it_interval = ns_to_timespec64(old_incr); } if (unlikely(ret)) { @@ -665,7 +736,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, * it as an overrun (thanks to bump_cpu_timer above). */ unlock_task_sighand(p, &flags); - goto out; + return ret; } if (new_expires != 0 && !(timer_flags & TIMER_ABSTIME)) { @@ -682,7 +753,6 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, arm_timer(timer, p); } - unlock_task_sighand(p, &flags); /* * Install the new reload setting, and * set up the signal and overrun bookkeeping. @@ -699,6 +769,8 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, timer->it_overrun_last = 0; timer->it_overrun = -1; + unlock_task_sighand(p, &flags); + if (new_expires != 0 && !(val < new_expires)) { /* * The designated time already passed, so we notify @@ -708,13 +780,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, cpu_timer_fire(timer); } - ret = 0; - out: - rcu_read_unlock(); - if (old) - old->it_interval = ns_to_timespec64(old_incr); - - return ret; + return 0; } static void posix_cpu_timer_get(struct k_itimer *timer, struct itimerspec64 *itp) @@ -978,19 +1044,12 @@ static void posix_cpu_timer_rearm(struct k_itimer *timer) { clockid_t clkid = CPUCLOCK_WHICH(timer->it_clock); struct task_struct *p; - struct sighand_struct *sighand; unsigned long flags; u64 now; - rcu_read_lock(); - p = cpu_timer_task_rcu(timer); - if (!p) - goto out; - - /* Protect timer list r/w in arm_timer() */ - sighand = lock_task_sighand(p, &flags); - if (unlikely(sighand == NULL)) - goto out; + p = timer_lock_sighand(timer, &flags); + if (unlikely(!p)) + return; /* * Fetch the current sample and update the timer's expiry time. @@ -1007,8 +1066,6 @@ static void posix_cpu_timer_rearm(struct k_itimer *timer) */ arm_timer(timer, p); unlock_task_sighand(p, &flags); -out: - rcu_read_unlock(); } /** -- 2.34.1

2 1

[PATCH OLK-6.6 0/5] mainline bpf
by Pu Lehui 31 Jul '26

31 Jul '26

David Windsor (1): bpf: Reject sleepable BPF_LSM_CGROUP programs at load time Jiri Olsa (1): bpf: Guard __get_user acesss with access_ok for uprobe_multi data Kaitao Cheng (1): bpf: Clear rb node linkage when freeing bpf_rb_root Xu Kuohai (2): bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno bpf: Add validation for bpf_set_retval argument include/linux/bpf_lsm.h | 6 ++++ kernel/bpf/bpf_lsm.c | 20 ++++++++++++ kernel/bpf/cgroup.c | 47 ++++++++++++++++++++-------- kernel/bpf/helpers.c | 11 +++++-- kernel/bpf/verifier.c | 67 +++++++++++++++++++++++++++++++++++++--- kernel/trace/bpf_trace.c | 11 +++++++ 6 files changed, 143 insertions(+), 19 deletions(-) -- 2.34.1

2 6

[PATCH openEuler-1.0-LTS] PCI: Remove old_size limit from bridge window sizing
by Hongtao Zhang 31 Jul '26

31 Jul '26

From: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> mainline inclusion from mainline-v7.0-rc1 commit f909e3ee3ed1a44202f09ac7e637a0f9ec372225 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9709 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- calculate_memsize() applies lower bound to the resource size before aligning the resource size making it impossible to shrink bridge window resources. I've not found any justification for this lower bound and nothing indicated it was to work around some HW issue. Prior to the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), releasing a bridge window during BAR resize resulted in clearing start and end address of the resource. Clearing addresses destroys the resource size as a side-effect, therefore nullifying the effect of the old size lower bound. After the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), BAR resize uses the aligned old size, which results in exceeding what fits into the parent window in some cases: xe 0030:03:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB xe 0030:03:00.0: BAR 0 [mem 0x620c000000000-0x620c000ffffff 64bit]: releasing xe 0030:03:00.0: BAR 2 [mem 0x6200000000000-0x620000fffffff 64bit pref]: releasing pci 0030:02:01.0: bridge window [mem 0x6200000000000-0x620001fffffff 64bit pref]: releasing pci 0030:01:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: releasing pci 0030:00:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: was not released (still contains assigned resources) pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] free space at [mem 0x6200400000000-0x62007ffffffff 64bit pref] pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] cannot fit 0x4000000000 required for 0030:01:00.0 bridging to [bus 02-04] The old size of 0x6200000000000-0x6203fbff0ffff resource was used as the lower bound which results in 0x4000000000 size request due to alignment. That exceeds what can fit into the parent window. Since the lower bound never even was enforced fully because the resource addresses were cleared when the bridge window is released, remove the old_size lower bound entirely and trust the calculated bridge window size is enough. This same problem may occur on io window side but seems less likely to cause issues due to general difference in alignment. Removing the lower bound may have other unforeseen consequences in case of io window so it's better to leave it as -next material if no problem is reported related to io window sizing (BAR resize shouldn't touch io windows anyway). Fixes: 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()") Reported-by: Simon Richter <Simon.Richter(a)hogyros.de> Link: https://lore.kernel.org/r/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/ Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Link: https://patch.msgid.link/20251219174036.16738-6-ilpo.jarvinen@linux.intel.c… Conflicts: drivers/pci/setup-bus.c [conflicts due to not mergered prerequisites] Signed-off-by: Zhang Hongtao <zhanghongtao35(a)huawei.com> --- drivers/pci/setup-bus.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 39d19302f3cbe..fe6f68d9e465b 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -794,15 +794,10 @@ static resource_size_t calculate_iosize(resource_size_t size, static resource_size_t calculate_memsize(resource_size_t size, resource_size_t min_size, resource_size_t size1, - resource_size_t old_size, resource_size_t align) { if (size < min_size) size = min_size; - if (old_size == 1) - old_size = 0; - if (size < old_size) - size = old_size; size = ALIGN(size + size1, align); return size; } @@ -1041,13 +1036,12 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, min_align = calculate_mem_align(aligns, max_order); min_align = max(min_align, window_alignment(bus, b_res->flags)); - size0 = calculate_memsize(size, min_size, 0, resource_size(b_res), min_align); + size0 = calculate_memsize(size, min_size, 0, min_align); add_align = max(min_align, add_align); if (children_add_size > add_size) add_size = children_add_size; size1 = (!realloc_head || (realloc_head && !add_size)) ? size0 : - calculate_memsize(size, min_size, add_size, - resource_size(b_res), add_align); + calculate_memsize(size, min_size, add_size, add_align); if (!size0 && !size1) { if (b_res->start || b_res->end) pci_info(bus->self, "disabling bridge window %pR to %pR (unused)\n", -- 2.43.0

2 1

[PATCH OLK-6.6] [Backport] nvmet-auth: validate reply message payload bounds against transfer length
by Lu Chentao 31 Jul '26

31 Jul '26

From: Tianchu Chen <flynnnchen(a)tencent.com> stable inclusion from stable-v6.6.145 commit 80cd28b56ab62d3e7ed0a7bf05282e6d3ee5b2a0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16615 CVE: CVE-2026-64319 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3a413ece2504c70aa34a20be4dafec04e8c741f9 ] nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes. A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp. With DH authentication configured, the OOB pointer is passed directly to sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication. Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before any access to the variable-length fields. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Cc: stable(a)vger.kernel.org Reviewed-by: Hannes Reinecke <hare(a)kernel.org> Signed-off-by: Tianchu Chen <flynnnchen(a)tencent.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/nvme/target/fabrics-cmd-auth.c [drivers/nvme/target/fabrics-cmd-auth.c: Added u32 tl parameter to nvmet_auth_reply and inserted bounds checks before accessing variable-length fields; call site updated accordingly.] Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/nvme/target/fabrics-cmd-auth.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/target/fabrics-cmd-auth.c b/drivers/nvme/target/fabrics-cmd-auth.c index c103eba96350..65a01343e553 100644 --- a/drivers/nvme/target/fabrics-cmd-auth.c +++ b/drivers/nvme/target/fabrics-cmd-auth.c @@ -107,17 +107,26 @@ static u16 nvmet_auth_negotiate(struct nvmet_req *req, void *d) __func__, ctrl->cntlid, req->sq->qid, nvme_auth_dhgroup_name(ctrl->dh_gid), ctrl->dh_gid); return 0; } -static u16 nvmet_auth_reply(struct nvmet_req *req, void *d) +static u16 nvmet_auth_reply(struct nvmet_req *req, void *d, u32 tl) { struct nvmet_ctrl *ctrl = req->sq->ctrl; struct nvmf_auth_dhchap_reply_data *data = d; - u16 dhvlen = le16_to_cpu(data->dhvlen); + u16 dhvlen; u8 *response; + if (tl < sizeof(*data)) + return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD; + + dhvlen = le16_to_cpu(data->dhvlen); + + /* Validate that hl and dhvlen fit within the transfer length */ + if (sizeof(*data) + 2 * (size_t)data->hl + dhvlen > tl) + return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD; + pr_debug("%s: ctrl %d qid %d: data hl %d cvalid %d dhvlen %u\n", __func__, ctrl->cntlid, req->sq->qid, data->hl, data->cvalid, dhvlen); if (dhvlen) { @@ -282,11 +291,11 @@ void nvmet_execute_auth_send(struct nvmet_req *req) goto done_kfree; } switch (data->auth_id) { case NVME_AUTH_DHCHAP_MESSAGE_REPLY: - status = nvmet_auth_reply(req, d); + status = nvmet_auth_reply(req, d, tl); if (status == 0) req->sq->dhchap_step = NVME_AUTH_DHCHAP_MESSAGE_SUCCESS1; else { req->sq->dhchap_step = -- 2.52.0

2 11

[PATCH OLK-5.10 0/2] CVE-2026-64560
by Jinjie Ruan 31 Jul '26

31 Jul '26

CVE-2026-64560. Thomas Gleixner (2): posix-cpu-timers: Make timespec to nsec conversion safe posix-cpu-timers: Prevent UAF caused by non-leader exec() race kernel/exit.c | 8 +- kernel/signal.c | 10 +- kernel/time/posix-cpu-timers.c | 187 ++++++++++++++++++++++----------- 3 files changed, 140 insertions(+), 65 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] posix-cpu-timers: Prevent UAF caused by non-leader exec() race
by Jinjie Ruan 31 Jul '26

31 Jul '26

From: Thomas Gleixner <tglx(a)kernel.org> stable inclusion from stable-v6.6.147 commit 12a891c773aeb5823d63dbd0cb2ab931d6c21c9b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16862 CVE: CVE-2026-64560 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 920f893f735e92ba3a1cd9256899a186b161928d upstream. Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is "harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary workaround for that in 2010 which survived about 10 years. The fix for the workaround changed the task pointer to a pid pointer, but failed to see the subtle race described above. So the Fixes tag picks that commit, which seems to be halfways accurate. Thanks to Frederic Weissbecker, Oleg Nesterov and Peter Zijlstra for review, feedback and suggestions and to Wongi and Jungwoo for the excellent bug report and analysis! Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") Reported-by: Wongi Lee <qw3rtyp0(a)gmail.com> Reported-by: Jungwoo Lee <jwlee2217(a)gmail.com> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Reviewed-by: Oleg Nesterov <oleg(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/exit.c | 8 +- kernel/signal.c | 10 +- kernel/time/posix-cpu-timers.c | 212 ++++++++++++++++++++------------- 3 files changed, 143 insertions(+), 87 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index ee7521131cad..28251ea0220b 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -204,7 +204,13 @@ static void __exit_signal(struct task_struct *tsk) * doing sigqueue_free() if we have SIGQUEUE_PREALLOC signals. */ flush_sigqueue(&tsk->pending); - tsk->sighand = NULL; + + /* + * Ensure that all preceeding state is visible. Pairs with + * the smp_acquire__after_ctrl_dep() in the sighand == NULL + * path of lock_task_sighand(). + */ + smp_store_release(&tsk->sighand, NULL); spin_unlock(&sighand->siglock); __cleanup_sighand(sighand); diff --git a/kernel/signal.c b/kernel/signal.c index 91019f737a94..dd2d4ebc4cf1 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1409,8 +1409,16 @@ struct sighand_struct *__lock_task_sighand(struct task_struct *tsk, rcu_read_lock(); for (;;) { sighand = rcu_dereference(tsk->sighand); - if (unlikely(sighand == NULL)) + if (unlikely(sighand == NULL)) { + /* + * Pairs with the smp_store_release() in + * __exit_signal(). It ensures that all state + * modifications to the task preceeding the store are + * visible to the callers of lock_task_sighand(). + */ + smp_acquire__after_ctrl_dep(); break; + } /* * This sighand can be already freed and even reused, but diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c index 9af1f2a72a0a..66e6ace0de29 100644 --- a/kernel/time/posix-cpu-timers.c +++ b/kernel/time/posix-cpu-timers.c @@ -461,6 +461,109 @@ static void disarm_timer(struct k_itimer *timer, struct task_struct *p) trigger_base_recalc_expires(timer, p); } +/* + * Lookup the task via timer->it.cpu.pid and attempt to lock the task's sighand. + * + * This can race with the reaping of the task: + * + * CPU0 CPU1 + * + * // Finds task + * p = pid_task(pid, pid_type); __exit_signal(p) + * lock(p, sighand); + * posix_cpu_timers*_exit(); + * sighand = lock_task_sighand(p); unhash_task(p); + * p->sighand = NULL; + * unlock(sighand); + * + * In this case sighand is NULL, which means the task and the associated timer + * queue cannot be longer accessed safely. + * + * __exit_signal() invokes posix_cpu_timers_exit() and if the thread group is + * dead it also invokes posix_cpu_timers_group_exit(). These functions delete + * all pending timers from the related timer queues. The POSIX timers (k_itimer) + * themself are still accessible, but not longer connected to the task. + * + * exec() works slightly differently. The task which exec()'s terminates all + * other threads in the thread group and runs __exit_signal() on them. As the + * thread group is not dead they only clean up the per task timers via + * posix_cpu_timers_exit(). + * + * As the TGID on exec() stays the same per process timers stay queued, if they + * are armed. This works without a problem when exec() is done by the thread + * group leader. If a non-leader thread exec()'s this can end up in the + * following scenario: + * + * CPU0 CPU1 + * // Returns old leader + * p = pid_task(pid, pid_type); de_thread() + * switch_leader() + * release_task(old leader) + * __exit_signal() + * old_leader->sighand = NULL; + * // Returns NULL + * sighand = lock_task_sighand(p) + * + * That's problematic for several functions: + * + * - posix_cpu_timer_del(): If the timer is still enqueued on the task the + * underlying k_itimer will be freed which results in a UAF in + * run_posix_cpu_timers() or on timerqueue related add/delete operations. + * If the timer is not enqueued, the failure is harmless + * + * - posix_cpu_timer_set(): Independent of the enqueued state that results in a + * transient failure which is user space visible (-ESRCH) for regular posix + * timers. But for the use case in do_cpu_nanosleep() it's the same UAF + * problem just that the timer is allocated on the stack. + * + * - posix_cpu_timer_rearm(): Timer is not enqueued at that point, but this + * silently ignores the rearm request, which is a functional problem as the + * timer wont expire anymore. + */ +static struct task_struct *timer_lock_sighand(struct k_itimer *timer, unsigned long *flags) +{ + enum pid_type type = clock_pid_type(timer->it_clock); + struct cpu_timer *ctmr = &timer->it.cpu; + + guard(rcu)(); + + for (;;) { + struct task_struct *t = pid_task(timer->it.cpu.pid, type); + + /* Fail if the task cannot be found. */ + if (!t) + break; + + /* Try to lock the task's sighand */ + if (lock_task_sighand(t, flags)) + return t; + + /* + * The next PID lookup might either fail or return the new + * leader. This is correct for both exit() and exec(). + */ + } + + /* + * If the timer is still enqueued, warn. There is nothing safe to do + * here as there might be two timers in there which are removed in + * parallel and that will cause more damage than good. This should never + * happen! + * + * Ensure that the stores to the timer and timerqueue are visible: + * + * __exit_signal() + * posix_cpu_timers*_exit() + * write_seqlock(seqlock) + * smp_wmb(); <------- + * __unhash_process() | !pid_task() + * ----> smp_rmb(); + * WARN_ON_ONCE(...) + */ + smp_rmb(); + WARN_ON_ONCE(ctmr->head || timerqueue_node_queued(&ctmr->node)); + return NULL; +} /* * Clean up a CPU-clock timer that is about to be destroyed. @@ -470,29 +573,13 @@ static void disarm_timer(struct k_itimer *timer, struct task_struct *p) */ static int posix_cpu_timer_del(struct k_itimer *timer) { - struct cpu_timer *ctmr = &timer->it.cpu; - struct sighand_struct *sighand; struct task_struct *p; unsigned long flags; int ret = 0; - rcu_read_lock(); - p = cpu_timer_task_rcu(timer); - if (!p) - goto out; + p = timer_lock_sighand(timer, &flags); - /* - * Protect against sighand release/switch in exit/exec and process/ - * thread timer list entry concurrent read/writes. - */ - sighand = lock_task_sighand(p, &flags); - if (unlikely(sighand == NULL)) { - /* - * This raced with the reaping of the task. The exit cleanup - * should have removed this timer from the timer queue. - */ - WARN_ON_ONCE(ctmr->head || timerqueue_node_queued(&ctmr->node)); - } else { + if (likely(p)) { if (timer->it.cpu.firing) ret = TIMER_RETRY; else @@ -501,10 +588,8 @@ static int posix_cpu_timer_del(struct k_itimer *timer) unlock_task_sighand(p, &flags); } -out: - rcu_read_unlock(); if (!ret) - put_pid(ctmr->pid); + put_pid(timer->it.cpu.pid); return ret; } @@ -626,21 +711,17 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, clockid_t clkid = CPUCLOCK_WHICH(timer->it_clock); u64 old_expires, new_expires, old_incr, val; struct cpu_timer *ctmr = &timer->it.cpu; - struct sighand_struct *sighand; struct task_struct *p; unsigned long flags; int ret = 0; - rcu_read_lock(); - p = cpu_timer_task_rcu(timer); - if (!p) { - /* - * If p has just been reaped, we can no - * longer get any information about it at all. - */ - rcu_read_unlock(); + p = timer_lock_sighand(timer, &flags); + /* + * If p has just been reaped, we can no longer get any information about + * it at all. + */ + if (!p) return -ESRCH; - } /* * Use the to_ktime conversion because that clamps the maximum @@ -648,20 +729,6 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, */ new_expires = ktime_to_ns(timespec64_to_ktime(new->it_value)); - /* - * Protect against sighand release/switch in exit/exec and p->cpu_timers - * and p->signal->cpu_timers read/write in arm_timer() - */ - sighand = lock_task_sighand(p, &flags); - /* - * If p has just been reaped, we can no - * longer get any information about it at all. - */ - if (unlikely(sighand == NULL)) { - rcu_read_unlock(); - return -ESRCH; - } - /* * Disarm any old timer after extracting its expiry time. */ @@ -710,6 +777,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, old->it_value.tv_sec = 0; } } + old->it_interval = ns_to_timespec64(old_incr); } if (unlikely(ret)) { @@ -720,7 +788,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, * it as an overrun (thanks to bump_cpu_timer above). */ unlock_task_sighand(p, &flags); - goto out; + return ret; } if (new_expires != 0 && !(timer_flags & TIMER_ABSTIME)) { @@ -733,11 +801,11 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, * arm the timer (we'll just fake it for timer_gettime). */ cpu_timer_setexpires(ctmr, new_expires); - if (new_expires != 0 && val < new_expires) { + if (new_expires != 0 && val < new_expires) arm_timer(timer, p); - } + else + trigger_base_recalc_expires(timer, p); - unlock_task_sighand(p, &flags); /* * Install the new reload setting, and * set up the signal and overrun bookkeeping. @@ -754,35 +822,18 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags, timer->it_overrun_last = 0; timer->it_overrun = -1; - if (val >= new_expires) { - if (new_expires != 0) { - /* - * The designated time already passed, so we notify - * immediately, even if the thread never runs to - * accumulate more time on this clock. - */ - cpu_timer_fire(timer); - } + unlock_task_sighand(p, &flags); + if (new_expires && val >= new_expires) { /* - * Make sure we don't keep around the process wide cputime - * counter or the tick dependency if they are not necessary. + * The designated time already passed, so we notify immediately, + * even if the thread never runs to accumulate more time on this + * clock. */ - sighand = lock_task_sighand(p, &flags); - if (!sighand) - goto out; - - if (!cpu_timer_queued(ctmr)) - trigger_base_recalc_expires(timer, p); - - unlock_task_sighand(p, &flags); + cpu_timer_fire(timer); } - out: - rcu_read_unlock(); - if (old) - old->it_interval = ns_to_timespec64(old_incr); - return ret; + return 0; } static void posix_cpu_timer_get(struct k_itimer *timer, struct itimerspec64 *itp) @@ -1048,19 +1099,12 @@ static void posix_cpu_timer_rearm(struct k_itimer *timer) { clockid_t clkid = CPUCLOCK_WHICH(timer->it_clock); struct task_struct *p; - struct sighand_struct *sighand; unsigned long flags; u64 now; - rcu_read_lock(); - p = cpu_timer_task_rcu(timer); - if (!p) - goto out; - - /* Protect timer list r/w in arm_timer() */ - sighand = lock_task_sighand(p, &flags); - if (unlikely(sighand == NULL)) - goto out; + p = timer_lock_sighand(timer, &flags); + if (unlikely(!p)) + return; /* * Fetch the current sample and update the timer's expiry time. @@ -1077,8 +1121,6 @@ static void posix_cpu_timer_rearm(struct k_itimer *timer) */ arm_timer(timer, p); unlock_task_sighand(p, &flags); -out: - rcu_read_unlock(); } /** -- 2.34.1

2 1

[PATCH OLK-6.6 0/3] backport olk6.6
by Chen Jinghuang 31 Jul '26

31 Jul '26

*** BLURB HERE *** Chen Jinghuang (3): cpuset: Fix prefer_cpus ineffectiveness by tracking prefer_cpus cgroup/cpuset.c: Comment out early when prefer_cpus cpumask equals cgroup/cpuset.c: Adapt schduler dynamic affinity for hotplug scenarios with cgroup v2 kernel/cgroup/cpuset.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) -- 2.34.1

2 4

[PATCH OLK-6.6] KVM: x86: Unconditionally recompute CR8 intercept on PPR update
by Zhang Kunbo 31 Jul '26

31 Jul '26

From: Carlos López <clopez(a)suse.de> stable inclusion from stable-v6.18.39 commit ff9c4c6428883182960cfe5c78928f0896d80ebc category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16812 CVE: CVE-2026-64513 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit bb365a506b1e6fb050c0fceaad354fe395385ef0 ] The TPR_THRESHOLD field in the VMCS is used by VMX to induce VM exits when the guest's virtual TPR falls under the specified threshold, allowing KVM to inject previously masked interrupts. KVM handles these VM exits in handle_tpr_below_threshold(). Commit eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") optimized this function by calling apic_update_ppr() instead of raising KVM_REQ_EVENT. apic_update_ppr() then raises KVM_REQ_EVENT if there is a pending, deliverable interrupt. However, if there are no new interrupts pending, apic_update_ppr() does not issue the request. Thus, kvm_lapic_update_cr8_intercept() and vmx_update_cr8_intercept() are not called before VM entry, which results in a high, stale TPR_THRESHOLD. This is problematic due to the following sentence in 28.2.1.1 "VM-Execution Control Fields" in the SDM: The following check is performed if the “use TPR shadow” VM-execution control is 1 and the “virtualize APIC accesses” and “virtual-interrupt delivery” VM-execution controls are both 0: the value of bits 3:0 of the TPR threshold VM-execution control field should not be greater than the value of bits 7:4 of VTPR. This error condition is typically not observed when KVM runs on a bare metal system because modern processors support APICv, which enables virtual-interrupt delivery, and which KVM uses when possible. This causes the processor to no longer generate TPR-below-threshold exits and to no longer check TPR_THRESHOLD on entry. However, when running on older platforms, or under nested virtualization on a hypervisor that does not support virtual-interrupt delivery and enforces this check (like Hyper-V) this can cause a VM entry failure with hardware error 0x7, as seen in [1]. Call kvm_lapic_update_cr8_intercept() if apic_update_ppr() does not find a deliverable interrupt (and thus does not raise KVM_REQ_EVENT). Remove calls to kvm_lapic_update_cr8_intercept() on paths that end up in apic_update_ppr(), as they now become redundant. This ensures that any path that updates the guest's PPR also figures out if KVM needs to wait for a TPR change (using TPR_THRESHOLD on VMX or CR8 intercepts on SVM). Link: https://github.com/coconut-svsm/svsm/issues/1081 [1] Tested-by: Stefano Garzarella <sgarzare(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") Signed-off-by: Carlos López <clopez(a)suse.de> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-ID: <20260618174347.1981064-3-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: arch/x86/kvm/x86.c arch/x86/kvm/lapic.c [c7722e5e1dae ("KVM: x86: Move update_cr8_intercept() to lapic.c") n ot merged] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kvm/lapic.c | 2 ++ arch/x86/kvm/x86.c | 5 +---- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 6ab159b0e326..f702019d008d 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -981,6 +981,8 @@ static void apic_update_ppr(struct kvm_lapic *apic) if (__apic_update_ppr(apic, &ppr) && apic_has_interrupt_for_ppr(apic, ppr) != -1) kvm_make_request(KVM_REQ_EVENT, apic->vcpu); + else + update_cr8_intercept(apic->vcpu); } void kvm_apic_update_ppr(struct kvm_vcpu *vcpu) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 191c350345b8..797de66edea5 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5123,7 +5123,6 @@ static int kvm_vcpu_ioctl_set_lapic(struct kvm_vcpu *vcpu, r = kvm_apic_set_state(vcpu, s); if (r) return r; - update_cr8_intercept(vcpu); return 0; } @@ -11953,8 +11952,6 @@ static int __set_sregs_common(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs, static_call_cond(kvm_x86_post_set_cr3)(vcpu, sregs->cr3); skip_dt_cr2_cr3: - kvm_set_cr8(vcpu, sregs->cr8); - *mmu_reset_needed |= vcpu->arch.efer != sregs->efer; static_call(kvm_x86_set_efer)(vcpu, sregs->efer); @@ -11987,7 +11984,7 @@ static int __set_sregs_common(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs, kvm_set_segment(vcpu, &sregs->tr, VCPU_SREG_TR); kvm_set_segment(vcpu, &sregs->ldt, VCPU_SREG_LDTR); - update_cr8_intercept(vcpu); + kvm_set_cr8(vcpu, sregs->cr8); /* Older userspace won't unhalt the vcpu on reset. */ if (kvm_vcpu_is_bsp(vcpu) && kvm_rip_read(vcpu) == 0xfff0 && -- 2.34.1

2 1

[PATCH OLK-6.6] [Backport] nvmet-auth: validate reply message payload bounds against transfer length
by Lu Chentao 31 Jul '26

31 Jul '26

From: Tianchu Chen <flynnnchen(a)tencent.com> stable inclusion from stable-v6.6.145 commit 80cd28b56ab62d3e7ed0a7bf05282e6d3ee5b2a0 category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3a413ece2504c70aa34a20be4dafec04e8c741f9 ] nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes. A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp. With DH authentication configured, the OOB pointer is passed directly to sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication. Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before any access to the variable-length fields. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Cc: stable(a)vger.kernel.org Reviewed-by: Hannes Reinecke <hare(a)kernel.org> Signed-off-by: Tianchu Chen <flynnnchen(a)tencent.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/nvme/target/fabrics-cmd-auth.c [drivers/nvme/target/fabrics-cmd-auth.c: Added u32 tl parameter to nvmet_auth_reply and inserted bounds checks before accessing variable-length fields; call site updated accordingly.] Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/nvme/target/fabrics-cmd-auth.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/target/fabrics-cmd-auth.c b/drivers/nvme/target/fabrics-cmd-auth.c index c103eba96350..65a01343e553 100644 --- a/drivers/nvme/target/fabrics-cmd-auth.c +++ b/drivers/nvme/target/fabrics-cmd-auth.c @@ -107,17 +107,26 @@ static u16 nvmet_auth_negotiate(struct nvmet_req *req, void *d) __func__, ctrl->cntlid, req->sq->qid, nvme_auth_dhgroup_name(ctrl->dh_gid), ctrl->dh_gid); return 0; } -static u16 nvmet_auth_reply(struct nvmet_req *req, void *d) +static u16 nvmet_auth_reply(struct nvmet_req *req, void *d, u32 tl) { struct nvmet_ctrl *ctrl = req->sq->ctrl; struct nvmf_auth_dhchap_reply_data *data = d; - u16 dhvlen = le16_to_cpu(data->dhvlen); + u16 dhvlen; u8 *response; + if (tl < sizeof(*data)) + return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD; + + dhvlen = le16_to_cpu(data->dhvlen); + + /* Validate that hl and dhvlen fit within the transfer length */ + if (sizeof(*data) + 2 * (size_t)data->hl + dhvlen > tl) + return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD; + pr_debug("%s: ctrl %d qid %d: data hl %d cvalid %d dhvlen %u\n", __func__, ctrl->cntlid, req->sq->qid, data->hl, data->cvalid, dhvlen); if (dhvlen) { @@ -282,11 +291,11 @@ void nvmet_execute_auth_send(struct nvmet_req *req) goto done_kfree; } switch (data->auth_id) { case NVME_AUTH_DHCHAP_MESSAGE_REPLY: - status = nvmet_auth_reply(req, d); + status = nvmet_auth_reply(req, d, tl); if (status == 0) req->sq->dhchap_step = NVME_AUTH_DHCHAP_MESSAGE_SUCCESS1; else { req->sq->dhchap_step = -- 2.52.0

2 11

[PATCH OLK-6.6] tracing: Bound synthetic-field strings with seq_buf
by Tengda Wu 31 Jul '26

31 Jul '26

From: Pengpeng Hou <pengpeng(a)iscas.ac.cn> stable inclusion from stable-v6.6.145 commit 0c584c27f6649a93ec12061cc779a4bd8f7c1434 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9691 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit f07883450eb14d1cf020b55d9f3a7ec5683bcd26 ] The synthetic field helpers build a prefixed synthetic variable name and a generated hist command in fixed MAX_FILTER_STR_VAL buffers. The current code appends those strings with raw strcat(), so long key lists, field names, or saved filters can run past the end of the staging buffers. Build both strings with seq_buf and propagate -E2BIG if either the synthetic variable name or the generated command exceeds MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while using the helper intended for bounded command construction. Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Tom Zanussi <tom.zanussi(a)linux.intel.com> Link: https://patch.msgid.link/20260430043350.57928-1-pengpeng@iscas.ac.cn Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Reviewed-by: Tom Zanussi <zanussi(a)kernel.org> Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> [ sdr: Moved struct seq_buf *s for upside-down x-mas tree formatting ] Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/trace_events_hist.c | 41 ++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 12 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index 78dd8a7ce221..a5fe1776d2a9 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -8,6 +8,7 @@ #include <linux/module.h> #include <linux/kallsyms.h> #include <linux/security.h> +#include <linux/seq_buf.h> #include <linux/mutex.h> #include <linux/slab.h> #include <linux/stacktrace.h> @@ -2947,13 +2948,22 @@ find_synthetic_field_var(struct hist_trigger_data *target_hist_data, { struct hist_field *event_var; char *synthetic_name; + struct seq_buf s; synthetic_name = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL); if (!synthetic_name) return ERR_PTR(-ENOMEM); - strcpy(synthetic_name, "synthetic_"); - strcat(synthetic_name, field_name); + seq_buf_init(&s, synthetic_name, MAX_FILTER_STR_VAL); + seq_buf_printf(&s, "synthetic_%s", field_name); + + /* Terminate synthetic_name with a NUL. */ + seq_buf_str(&s); + + if (seq_buf_has_overflowed(&s)) { + kfree(synthetic_name); + return ERR_PTR(-E2BIG); + } event_var = find_event_var(target_hist_data, system, event_name, synthetic_name); @@ -2999,6 +3009,7 @@ create_field_var_hist(struct hist_trigger_data *target_hist_data, struct hist_field *key_field; struct hist_field *event_var; char *saved_filter; + struct seq_buf s; char *cmd; int ret; @@ -3043,28 +3054,34 @@ create_field_var_hist(struct hist_trigger_data *target_hist_data, return ERR_PTR(-ENOMEM); } + seq_buf_init(&s, cmd, MAX_FILTER_STR_VAL); + /* Use the same keys as the compatible histogram */ - strcat(cmd, "keys="); + seq_buf_puts(&s, "keys="); for_each_hist_key_field(i, hist_data) { key_field = hist_data->fields[i]; if (!first) - strcat(cmd, ","); - strcat(cmd, key_field->field->name); + seq_buf_putc(&s, ','); + seq_buf_puts(&s, key_field->field->name); first = false; } /* Create the synthetic field variable specification */ - strcat(cmd, ":synthetic_"); - strcat(cmd, field_name); - strcat(cmd, "="); - strcat(cmd, field_name); + seq_buf_printf(&s, ":synthetic_%s=%s", field_name, field_name); /* Use the same filter as the compatible histogram */ saved_filter = find_trigger_filter(hist_data, file); - if (saved_filter) { - strcat(cmd, " if "); - strcat(cmd, saved_filter); + if (saved_filter) + seq_buf_printf(&s, " if %s", saved_filter); + + /* Terminate cmd with a NUL. */ + seq_buf_str(&s); + + if (seq_buf_has_overflowed(&s)) { + kfree(cmd); + kfree(var_hist); + return ERR_PTR(-E2BIG); } var_hist->cmd = kstrdup(cmd, GFP_KERNEL); -- 2.34.1

2 1

[PATCH OLK-5.10] ksmbd: serialize QUERY_DIRECTORY requests per file
by Lai Zewei 31 Jul '26

31 Jul '26

mainline inclusion from mainline-v7.2-rc1 commit be6d26bf27499977c746abc163659915082348d8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16688 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- smb2_query_dir() stores a pointer to its stack-allocated private data in the ksmbd_file readdir_data. Concurrent QUERY_DIRECTORY requests using the same file handle can overwrite this pointer while an iterate_dir() callback is still using it, resulting in a stack use-after-free. Add a per-file mutex and hold it while accessing the shared directory enumeration state. The lock covers scan restart, dot entry state, readdir_data setup and iteration, and response construction. This prevents another request from replacing readdir_data.private before the current request has finished using it and also serializes the shared file position. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-30527 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/smb2pdu.c fs/ksmbd/vfs_cache.c fs/ksmbd/vfs_cache.h [ctx conflicts] Signed-off-by: Lai Zewei <laizewei3(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 4 ++++ fs/ksmbd/vfs_cache.c | 1 + fs/ksmbd/vfs_cache.h | 2 ++ 3 files changed, 7 insertions(+) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index d799f2bbd73f..ff3bcd2f7c46 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -3985,6 +3985,8 @@ int smb2_query_dir(struct ksmbd_work *work) ksmbd_debug(SMB, "Search pattern is %s\n", srch_ptr); } + mutex_lock(&dir_fp->readdir_lock); + ksmbd_debug(SMB, "Directory name is %s\n", dir_fp->filename); if (srch_flag & SMB2_REOPEN || srch_flag & SMB2_RESTART_SCANS) { @@ -4073,6 +4075,7 @@ int smb2_query_dir(struct ksmbd_work *work) inc_rfc1001_len(work->response_buf, 8 + d_info.data_count); } + mutex_unlock(&dir_fp->readdir_lock); kfree(srch_ptr); ksmbd_fd_put(work, dir_fp); ksmbd_revert_fsids(work); @@ -4080,6 +4083,7 @@ int smb2_query_dir(struct ksmbd_work *work) err_out: pr_err("error while processing smb2 query dir rc = %d\n", rc); + mutex_unlock(&dir_fp->readdir_lock); kfree(srch_ptr); err_out2: diff --git a/fs/ksmbd/vfs_cache.c b/fs/ksmbd/vfs_cache.c index 2a445befcc62..a56f47a5ad32 100644 --- a/fs/ksmbd/vfs_cache.c +++ b/fs/ksmbd/vfs_cache.c @@ -564,6 +564,7 @@ struct ksmbd_file *ksmbd_open_fd(struct ksmbd_work *work, struct file *filp) INIT_LIST_HEAD(&fp->node); INIT_LIST_HEAD(&fp->lock_list); spin_lock_init(&fp->f_lock); + mutex_init(&fp->readdir_lock); atomic_set(&fp->refcount, 1); fp->filp = filp; diff --git a/fs/ksmbd/vfs_cache.h b/fs/ksmbd/vfs_cache.h index 36239ce31afd..aa0ede0019aa 100644 --- a/fs/ksmbd/vfs_cache.h +++ b/fs/ksmbd/vfs_cache.h @@ -8,6 +8,7 @@ #include <linux/file.h> #include <linux/fs.h> +#include <linux/mutex.h> #include <linux/rwsem.h> #include <linux/spinlock.h> #include <linux/idr.h> @@ -98,6 +99,7 @@ struct ksmbd_file { /* if ls is happening on directory, below is valid*/ struct ksmbd_readdir_data readdir_data; + struct mutex readdir_lock; int dot_dotdot[2]; }; -- 2.52.0

2 5

[PATCH v4 OLK-5.10 00/15] Fix CVE-2026-46054
by Cai Xinchen 30 Jul '26

30 Jul '26

v3->v4: Add GET_FILE_WRAP in alloc_empty_file and alloc_empty_file_noaccount in error path use kmem_cache_free. There is no need to set vma->vm_file to user_file because in __mmap_region handle error path, it will be set NULL. v2->v3: Fix lsm: add backing_file LSM hooks in ovl_mmap when security_mmap_backing_file failed, fput realfile but not set vma->vm_file to original user_file. v1->v2: Add commit 9fe595fad54d ("selinux: fix incorrect execmem checks on overlayfs") ovl_open_realfile reletion code feature patch ("ovl: pass layer mnt to ovl_open_realfile: ovl_open_realfile reletion.") init_file code refactoring patch ("fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers") backing_file structure and backing_file_open function reletion features: patch ("fs: use backing_file container for internal files with "fake" f_path") patch ("fs: move cleanup from init_file() into its callers") bpf_fd_pass const warning fix patch ("lsm: constify the 'file' parameter in security_binder_transfer_file()") code refactoring: store real path instead of fake path in backing file f_path patch ("fs: get mnt_writers count for an open backing file's real path") patch ("fs: create helper file_user_path() for user displayed mapped file path") patch ("fs: store real path instead of fake path in backing file f_path") patch ("ovl: Fix nested backing file paths") patch ("perf/core: Fix MMAP event path names with backing files") backing_file const warning fix patch ("fs: constify file ptr in backing_file accessor helpers") SELinux overlay backing_file mmap/mprotect check prepare for lsm function: patch ("fs: prepare for adding LSM blob to backing_file") patch ("lsm: add backing_file LSM hooks") CVE-2026-46054 fix: Add SELinux lsm hooks for backing_file mmap/mprotect patch ("selinux: fix overlayfs mmap() and mprotect() access checks") bugfix commit 9fe595fad54d ("selinux: fix incorrect execmem checks on overlayfs") to fix mount check PROCESS__EXEC to the mounter Adrian Hunter (1): perf/core: Fix MMAP event path names with backing files Amir Goldstein (9): [Backport] ovl: pass layer mnt to ovl_open_realfile() fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers fs: use backing_file container for internal files with "fake" f_path fs: move cleanup from init_file() into its callers fs: get mnt_writers count for an open backing file's real path fs: create helper file_user_path() for user displayed mapped file path fs: store real path instead of fake path in backing file f_path fs: constify file ptr in backing_file accessor helpers fs: prepare for adding LSM blob to backing_file André Almeida (1): ovl: Fix nested backing file paths Khadija Kamran (1): lsm: constify the 'file' parameter in security_binder_transfer_file() Ondrej Mosnacek (1): selinux: fix incorrect execmem checks on overlayfs Paul Moore (2): lsm: add backing_file LSM hooks selinux: fix overlayfs mmap() and mprotect() access checks arch/arc/kernel/troubleshoot.c | 6 +- fs/file_table.c | 139 +++++++++++++--- fs/internal.h | 18 ++- fs/open.c | 76 ++++++--- fs/overlayfs/file.c | 34 ++-- fs/overlayfs/overlayfs.h | 1 + fs/overlayfs/super.c | 16 +- fs/overlayfs/util.c | 14 ++ fs/proc/base.c | 2 +- fs/proc/nommu.c | 2 +- fs/proc/task_mmu.c | 4 +- fs/proc/task_nommu.c | 2 +- include/linux/fs.h | 44 ++++- include/linux/lsm_audit.h | 2 +- include/linux/lsm_hook_defs.h | 7 +- include/linux/lsm_hooks.h | 1 + include/linux/security.h | 26 ++- kernel/events/core.c | 2 +- kernel/trace/trace_output.c | 2 +- security/security.c | 112 ++++++++++++- security/selinux/hooks.c | 256 ++++++++++++++++++++++-------- security/selinux/include/objsec.h | 11 ++ 22 files changed, 637 insertions(+), 140 deletions(-) -- 2.18.0.huawei.25

2 16

[PATCH OLK-6.6] selinux: fix incorrect execmem checks on overlayfs
by Cai Xinchen 30 Jul '26

30 Jul '26

From: Ondrej Mosnacek <omosnace(a)redhat.com> mainline inclusion from mainline-v7.2-rc4 commit 9fe595fad54d4ac6a402edb3f60bec859d52cea6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9692 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The commit fixing the overlayfs mmap() and mprotect() access checks failed to skip the execmem check in __file_map_prot_check() for the case where the "mounter check" is being performed. This check should be performed only against the credentials of the task that is calling mmap()/mprotect(), since it doesn't pertain to the file itself, but rather just gates the ability of the calling task to get an executable memory mapping in general. The purpose of the "mounter check" is to guard against using an overlayfs mount to gain file access that would otherwise be denied to the mounter. For execmem this is not relevant, as there is no further file access granted based on it (notice that the file's context is not used as the target in the check), so checking it also against the mounter credentials would be incorrect. Fix this by passing a boolean to [__]file_map_prot_check() and selinux_mmap_file_common() that indicates if we are doing the "mounter check" and skiping the execmem check in that case. Since this boolean also indicates if we use current_cred() or the mounter cred as the subject, also remove the "cred" argument from these functions and determine it based on the boolean and the file struct. Cc: stable(a)vger.kernel.org Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com> Reviewed-by: Stephen Smalley <stephen.smalley.work(a)gmail.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- security/selinux/hooks.c | 42 +++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 2d9f365022cb..b3d93234a4c3 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -3794,9 +3794,9 @@ static int selinux_file_ioctl_compat(struct file *file, unsigned int cmd, static int default_noexec __ro_after_init; -static int __file_map_prot_check(const struct cred *cred, - const struct file *file, unsigned long prot, - bool shared, bool bf_user_file) +static int __file_map_prot_check(const struct file *file, unsigned long prot, + bool shared, bool mounter_check, + bool bf_user_file) { struct inode *inode = NULL; bool prot_exec = prot & PROT_EXEC; @@ -3809,10 +3809,10 @@ static int __file_map_prot_check(const struct cred *cred, inode = file_inode(file); } - if (default_noexec && prot_exec && + if (!mounter_check && default_noexec && prot_exec && (!file || IS_PRIVATE(inode) || (!shared && prot_write))) { int rc; - u32 sid = cred_sid(cred); + u32 sid = current_sid(); /* * We are making executable an anonymous mapping or a private @@ -3825,6 +3825,8 @@ static int __file_map_prot_check(const struct cred *cred, } if (file) { + const struct cred *cred = mounter_check ? + file->f_cred : current_cred(); /* "read" always possible, "write" only if shared */ u32 av = FILE__READ; if (shared && prot_write) @@ -3838,11 +3840,11 @@ static int __file_map_prot_check(const struct cred *cred, return 0; } -static inline int file_map_prot_check(const struct cred *cred, - const struct file *file, - unsigned long prot, bool shared) +static inline int file_map_prot_check(const struct file *file, + unsigned long prot, bool shared, + bool mounter_check) { - return __file_map_prot_check(cred, file, prot, shared, false); + return __file_map_prot_check(file, prot, shared, mounter_check, false); } static int selinux_mmap_addr(unsigned long addr) @@ -3858,12 +3860,14 @@ static int selinux_mmap_addr(unsigned long addr) return rc; } -static int selinux_mmap_file_common(const struct cred *cred, struct file *file, - unsigned long prot, bool shared) +static int selinux_mmap_file_common(struct file *file, unsigned long prot, + bool shared, bool mounter_check) { if (file) { int rc; struct common_audit_data ad; + const struct cred *cred = mounter_check ? + file->f_cred : current_cred(); ad.type = LSM_AUDIT_DATA_FILE; ad.u.file = file; @@ -3872,15 +3876,16 @@ static int selinux_mmap_file_common(const struct cred *cred, struct file *file, return rc; } - return file_map_prot_check(cred, file, prot, shared); + return file_map_prot_check(file, prot, shared, mounter_check); } static int selinux_mmap_file(struct file *file, unsigned long reqprot __always_unused, unsigned long prot, unsigned long flags) { - return selinux_mmap_file_common(current_cred(), file, prot, - (flags & MAP_TYPE) == MAP_SHARED); + return selinux_mmap_file_common(file, prot, + (flags & MAP_TYPE) == MAP_SHARED, + false); } /** @@ -3912,8 +3917,9 @@ static int selinux_mmap_backing_file(struct vm_area_struct *vma, if (vma->vm_flags & VM_EXEC) prot |= PROT_EXEC; - return selinux_mmap_file_common(backing_file->f_cred, backing_file, - prot, vma->vm_flags & VM_SHARED); + return selinux_mmap_file_common(backing_file, prot, + vma->vm_flags & VM_SHARED, + true); } static int selinux_file_mprotect(struct vm_area_struct *vma, @@ -3974,11 +3980,11 @@ static int selinux_file_mprotect(struct vm_area_struct *vma, } } - rc = __file_map_prot_check(cred, file, prot, shared, backing_file); + rc = __file_map_prot_check(file, prot, shared, false, backing_file); if (rc) return rc; if (backing_file) { - rc = file_map_prot_check(file->f_cred, file, prot, shared); + rc = file_map_prot_check(file, prot, shared, true); if (rc) return rc; } -- 2.18.0.huawei.25

2 1

[PATCH OLK-6.6 0/6] bpf back main
by Pu Lehui 30 Jul '26

30 Jul '26

From: Pu Lehui <pulehui(a)huaweicloud.com> David Windsor (1): bpf: Reject sleepable BPF_LSM_CGROUP programs at load time Jiri Olsa (1): bpf: Guard __get_user acesss with access_ok for uprobe_multi data Kaitao Cheng (1): bpf: Clear rb node linkage when freeing bpf_rb_root Mykyta Yatsenko (1): bpf: Fix NMI/tracepoint re-entry deadlock on lru locks Xu Kuohai (2): bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno bpf: Add validation for bpf_set_retval argument include/linux/bpf_lsm.h | 6 ++++ kernel/bpf/bpf_lru_list.h | 25 ++++++++++++---- kernel/bpf/bpf_lsm.c | 20 +++++++++++++ kernel/bpf/cgroup.c | 47 +++++++++++++++++++++--------- kernel/bpf/helpers.c | 11 +++++-- kernel/bpf/verifier.c | 61 +++++++++++++++++++++++++++++++++++++-- kernel/trace/bpf_trace.c | 11 +++++++ 7 files changed, 158 insertions(+), 23 deletions(-) -- 2.34.1

2 7

[PATCH] selinux: fix incorrect execmem checks on overlayfs
by Cai Xinchen 30 Jul '26

30 Jul '26

From: Ondrej Mosnacek <omosnace(a)redhat.com> mainline inclusion from mainline-v7.2-rc4 commit 9fe595fad54d4ac6a402edb3f60bec859d52cea6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9692 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The commit fixing the overlayfs mmap() and mprotect() access checks failed to skip the execmem check in __file_map_prot_check() for the case where the "mounter check" is being performed. This check should be performed only against the credentials of the task that is calling mmap()/mprotect(), since it doesn't pertain to the file itself, but rather just gates the ability of the calling task to get an executable memory mapping in general. The purpose of the "mounter check" is to guard against using an overlayfs mount to gain file access that would otherwise be denied to the mounter. For execmem this is not relevant, as there is no further file access granted based on it (notice that the file's context is not used as the target in the check), so checking it also against the mounter credentials would be incorrect. Fix this by passing a boolean to [__]file_map_prot_check() and selinux_mmap_file_common() that indicates if we are doing the "mounter check" and skiping the execmem check in that case. Since this boolean also indicates if we use current_cred() or the mounter cred as the subject, also remove the "cred" argument from these functions and determine it based on the boolean and the file struct. Cc: stable(a)vger.kernel.org Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com> Reviewed-by: Stephen Smalley <stephen.smalley.work(a)gmail.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- security/selinux/hooks.c | 42 +++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 2d9f365022cb..b3d93234a4c3 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -3794,9 +3794,9 @@ static int selinux_file_ioctl_compat(struct file *file, unsigned int cmd, static int default_noexec __ro_after_init; -static int __file_map_prot_check(const struct cred *cred, - const struct file *file, unsigned long prot, - bool shared, bool bf_user_file) +static int __file_map_prot_check(const struct file *file, unsigned long prot, + bool shared, bool mounter_check, + bool bf_user_file) { struct inode *inode = NULL; bool prot_exec = prot & PROT_EXEC; @@ -3809,10 +3809,10 @@ static int __file_map_prot_check(const struct cred *cred, inode = file_inode(file); } - if (default_noexec && prot_exec && + if (!mounter_check && default_noexec && prot_exec && (!file || IS_PRIVATE(inode) || (!shared && prot_write))) { int rc; - u32 sid = cred_sid(cred); + u32 sid = current_sid(); /* * We are making executable an anonymous mapping or a private @@ -3825,6 +3825,8 @@ static int __file_map_prot_check(const struct cred *cred, } if (file) { + const struct cred *cred = mounter_check ? + file->f_cred : current_cred(); /* "read" always possible, "write" only if shared */ u32 av = FILE__READ; if (shared && prot_write) @@ -3838,11 +3840,11 @@ static int __file_map_prot_check(const struct cred *cred, return 0; } -static inline int file_map_prot_check(const struct cred *cred, - const struct file *file, - unsigned long prot, bool shared) +static inline int file_map_prot_check(const struct file *file, + unsigned long prot, bool shared, + bool mounter_check) { - return __file_map_prot_check(cred, file, prot, shared, false); + return __file_map_prot_check(file, prot, shared, mounter_check, false); } static int selinux_mmap_addr(unsigned long addr) @@ -3858,12 +3860,14 @@ static int selinux_mmap_addr(unsigned long addr) return rc; } -static int selinux_mmap_file_common(const struct cred *cred, struct file *file, - unsigned long prot, bool shared) +static int selinux_mmap_file_common(struct file *file, unsigned long prot, + bool shared, bool mounter_check) { if (file) { int rc; struct common_audit_data ad; + const struct cred *cred = mounter_check ? + file->f_cred : current_cred(); ad.type = LSM_AUDIT_DATA_FILE; ad.u.file = file; @@ -3872,15 +3876,16 @@ static int selinux_mmap_file_common(const struct cred *cred, struct file *file, return rc; } - return file_map_prot_check(cred, file, prot, shared); + return file_map_prot_check(file, prot, shared, mounter_check); } static int selinux_mmap_file(struct file *file, unsigned long reqprot __always_unused, unsigned long prot, unsigned long flags) { - return selinux_mmap_file_common(current_cred(), file, prot, - (flags & MAP_TYPE) == MAP_SHARED); + return selinux_mmap_file_common(file, prot, + (flags & MAP_TYPE) == MAP_SHARED, + false); } /** @@ -3912,8 +3917,9 @@ static int selinux_mmap_backing_file(struct vm_area_struct *vma, if (vma->vm_flags & VM_EXEC) prot |= PROT_EXEC; - return selinux_mmap_file_common(backing_file->f_cred, backing_file, - prot, vma->vm_flags & VM_SHARED); + return selinux_mmap_file_common(backing_file, prot, + vma->vm_flags & VM_SHARED, + true); } static int selinux_file_mprotect(struct vm_area_struct *vma, @@ -3974,11 +3980,11 @@ static int selinux_file_mprotect(struct vm_area_struct *vma, } } - rc = __file_map_prot_check(cred, file, prot, shared, backing_file); + rc = __file_map_prot_check(file, prot, shared, false, backing_file); if (rc) return rc; if (backing_file) { - rc = file_map_prot_check(file->f_cred, file, prot, shared); + rc = file_map_prot_check(file, prot, shared, true); if (rc) return rc; } -- 2.18.0.huawei.25

1 0

[PATCH OLK-6.6 0/2] Fix CVE-2026-64352
by Tengda Wu 30 Jul '26

30 Jul '26

Fix CVE-2026-64352. Andrii Nakryiko (1): bpf: Consistently use bpf_rcu_lock_held() everywhere Vlad Poenaru (1): bpf: Allow LPM map access from sleepable BPF programs include/linux/bpf.h | 3 +++ include/linux/bpf_local_storage.h | 3 --- kernel/bpf/hashtab.c | 21 +++++++-------------- kernel/bpf/helpers.c | 12 ++++-------- kernel/bpf/lpm_trie.c | 10 ++++------ 5 files changed, 18 insertions(+), 31 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] cgroup/rstat: avoid disabling irqs for O(num_cpu)
by Cai Xinchen 30 Jul '26

30 Jul '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.15-rc1 commit 0efc297a3c4974dbd609ee36fc6345720b6ca735 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9685 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- cgroup_rstat_flush_locked() grabs the irq safe cgroup_rstat_lock while iterating all possible cpus. It only drops the lock if there is scheduler or spin lock contention. If neither, then interrupts can be disabled for a long time. On large machines this can disable interrupts for a long enough time to drop network packets. On 400+ CPU machines I've seen interrupt disabled for over 40 msec. Prevent rstat from disabling interrupts while processing all possible cpus. Instead drop and reacquire cgroup_rstat_lock for each cpu. This approach was previously discussed in https://lore.kernel.org/lkml/ZBz%2FV5a7%2F6PZeM7S@slm.duckdns.org/, though this was in the context of an non-irq rstat spin lock. Benchmark this change with: 1) a single stat_reader process with 400 threads, each reading a test memcg's memory.stat repeatedly for 10 seconds. 2) 400 memory hog processes running in the test memcg and repeatedly charging memory until oom killed. Then they repeat charging and oom killing. v6.14-rc6 with CONFIG_IRQSOFF_TRACER with stat_reader and hogs, finds interrupts are disabled by rstat for 45341 usec: # => started at: _raw_spin_lock_irq # => ended at: cgroup_rstat_flush # # # _------=> CPU# # / _-----=> irqs-off/BH-disabled # | / _----=> need-resched # || / _---=> hardirq/softirq # ||| / _--=> preempt-depth # |||| / _-=> migrate-disable # ||||| / delay # cmd pid |||||| time | caller # \ / |||||| \ | / stat_rea-96532 52d.... 0us*: _raw_spin_lock_irq stat_rea-96532 52d.... 45342us : cgroup_rstat_flush stat_rea-96532 52d.... 45342us : tracer_hardirqs_on <-cgroup_rstat_flush stat_rea-96532 52d.... 45343us : <stack trace> => memcg1_stat_format => memory_stat_format => memory_stat_show => seq_read_iter => vfs_read => ksys_read => do_syscall_64 => entry_SYSCALL_64_after_hwframe With this patch the CONFIG_IRQSOFF_TRACER doesn't find rstat to be the longest holder. The longest irqs-off holder has irqs disabled for 4142 usec, a huge reduction from previous 45341 usec rstat finding. Running stat_reader memory.stat reader for 10 seconds: - without memory hogs: 9.84M accesses => 12.7M accesses - with memory hogs: 9.46M accesses => 11.1M accesses The throughput of memory.stat access improves. The mode of memory.stat access latency after grouping by of 2 buckets: - without memory hogs: 64 usec => 16 usec - with memory hogs: 64 usec => 8 usec The memory.stat latency improves. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Greg Thelen <gthelen(a)google.com> Tested-by: Greg Thelen <gthelen(a)google.com> Acked-by: Michal Koutný <mkoutny(a)suse.com> Reviewed-by: Yosry Ahmed <yosry.ahmed(a)linux.dev> Signed-off-by: Tejun Heo <tj(a)kernel.org> Conflicts: kernel/cgroup/rstat.c [Use spin_(un)lock_irq instead of __cgroup_rstat_(un)lock in 6.6] Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- kernel/cgroup/rstat.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c index b589868cc85c..ea5a21dc9df3 100644 --- a/kernel/cgroup/rstat.c +++ b/kernel/cgroup/rstat.c @@ -205,12 +205,10 @@ static void cgroup_rstat_flush_locked(struct cgroup *cgrp) raw_spin_unlock_irqrestore(cpu_lock, flags); /* play nice and yield if necessary */ - if (need_resched() || spin_needbreak(&cgroup_rstat_lock)) { - spin_unlock_irq(&cgroup_rstat_lock); - if (!cond_resched()) - cpu_relax(); - spin_lock_irq(&cgroup_rstat_lock); - } + spin_unlock_irq(&cgroup_rstat_lock); + if (!cond_resched()) + cpu_relax(); + spin_lock_irq(&cgroup_rstat_lock); } } -- 2.18.0.huawei.25

2 1

[PATCH OLK-6.6] udf: validate free block extents against the partition length
by Lai Zewei 30 Jul '26

30 Jul '26

stable inclusion from stable-v6.6.145 commit fb49099206c5c57af28a157249fa7bcb5518f99e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16620 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array. Fixes: 56e69e59751d ("udf: prevent integer overflow in udf_bitmap_free_blocks()") Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Link: https://patch.msgid.link/20260515142327.1120767-1-michael.bommarito@gmail.c… Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Lai Zewei <laizewei3(a)huawei.com> --- fs/udf/balloc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c index f5de2030e769..e3bf8122b7dc 100644 --- a/fs/udf/balloc.c +++ b/fs/udf/balloc.c @@ -82,8 +82,9 @@ static int __load_block_bitmap(struct super_block *sb, int nr_groups = bitmap->s_nr_groups; if (block_group >= nr_groups) { - udf_debug("block_group (%u) > nr_groups (%d)\n", + udf_debug("block_group (%u) >= nr_groups (%d)\n", block_group, nr_groups); + return -EFSCORRUPTED; } if (bitmap->s_block_bitmap[block_group]) { @@ -679,7 +680,7 @@ void udf_free_blocks(struct super_block *sb, struct inode *inode, if (check_add_overflow(bloc->logicalBlockNum, offset, &blk) || check_add_overflow(blk, count, &blk) || - bloc->logicalBlockNum + count > map->s_partition_len) { + blk > map->s_partition_len) { udf_debug("Invalid request to free blocks: (%d, %u), off %u, " "len %u, partition len %u\n", partition, bloc->logicalBlockNum, offset, count, -- 2.52.0

2 7

[PATCH OLK-6.6] iov_iter: Fix potential underflow in iov_iter_extract_xarray_pages()
by Chen Jinghuang 30 Jul '26

30 Jul '26

From: David Howells <dhowells(a)redhat.com> mainline inclusion from mainline-v7.2-rc2 commit 55f4bb9373ca4a521f3b0119366db92715a39b81 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9684 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… -------------------------------- In iov_iter_extract_xarray_pages(), if no pages are extracted because there's a hole (or something otherwise unextractable) in the xarray, then the calculation of maxsize at the end can go wrong if the starting offset is not zero. Fix this by returning 0 in such a case and freeing the page array if allocated here rather than being passed in. Note that in the near future, ITER_XARRAY should be removed. Fixes: 7d58fe731028 ("iov_iter: Add a function to extract a page list from an iterator") Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Link: https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.c… Signed-off-by: David Howells <dhowells(a)redhat.com> Link: https://patch.msgid.link/20260625140640.3116900-6-dhowells@redhat.com Reviewed-by: Christoph Hellwig <hch(a)lst.de> cc: Paulo Alcantara <pc(a)manguebit.org> cc: Matthew Wilcox <willy(a)infradead.org> cc: Christoph Hellwig <hch(a)infradead.org> cc: Jens Axboe <axboe(a)kernel.dk> cc: Mike Marshall <hubcap(a)omnibond.com> cc: netfs(a)lists.linux.dev cc: linux-fsdevel(a)vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner(a)kernel.org> Conflicts: lib/iov_iter.c [a little context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- lib/iov_iter.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 0b8fc9831225..a4cc8d68b409 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -1625,6 +1625,7 @@ static ssize_t iov_iter_extract_xarray_pages(struct iov_iter *i, struct page *page, **p; unsigned int nr = 0, offset; loff_t pos = i->xarray_start + i->iov_offset; + bool will_alloc = !*pages; pgoff_t index = pos >> PAGE_SHIFT; XA_STATE(xas, i->xarray, index); @@ -1653,6 +1654,14 @@ static ssize_t iov_iter_extract_xarray_pages(struct iov_iter *i, } rcu_read_unlock(); + if (!nr) { + if (will_alloc) { + kvfree(*pages); + *pages = NULL; + } + return 0; + } + maxsize = min_t(size_t, nr * PAGE_SIZE - offset, maxsize); iov_iter_advance(i, maxsize); return maxsize; -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: Allow LPM map access from sleepable BPF programs
by Tengda Wu 30 Jul '26

30 Jul '26

From: Vlad Poenaru <vlad.wing(a)gmail.com> stable inclusion from stable-v6.6.145 commit ec662a8b2cde01e76b37ccd4b992d0342299e69c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16648 CVE: CVE-2026-64352 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2f884d371fafea137afea504d49ee4a7c8d7985b ] trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to "c || rcu_read_lock_held()", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched. Fixes: 694cea395fde ("bpf: Allow RCU-protected lookups to happen from bh context") Cc: stable(a)vger.kernel.org Signed-off-by: Vlad Poenaru <vlad.wing(a)gmail.com> Reviewed-by: Emil Tsalapatis <emil(a)etsalapatis.com> Link: https://lore.kernel.org/r/20260609135558.193287-2-vlad.wing@gmail.com Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/bpf/lpm_trie.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c index c4f1d465ae35..7c7cacf9fa59 100644 --- a/kernel/bpf/lpm_trie.c +++ b/kernel/bpf/lpm_trie.c @@ -236,7 +236,7 @@ static void *trie_lookup_elem(struct bpf_map *map, void *_key) /* Start walking the trie from the root node ... */ - for (node = rcu_dereference_check(trie->root, rcu_read_lock_bh_held()); + for (node = rcu_dereference_check(trie->root, bpf_rcu_lock_held()); node;) { unsigned int next_bit; size_t matchlen; @@ -270,7 +270,7 @@ static void *trie_lookup_elem(struct bpf_map *map, void *_key) */ next_bit = extract_bit(key->data, node->prefixlen); node = rcu_dereference_check(node->child[next_bit], - rcu_read_lock_bh_held()); + bpf_rcu_lock_held()); } if (!found) -- 2.34.1

2 1

[PATCH OLK-6.6] perf/core: Detach event groups during remove_on_exec
by Luo Gengkun 30 Jul '26

30 Jul '26

From: Taeyang Lee <0wn(a)theori.io> stable inclusion from stable-v6.6.145 commit 4cdb1b3ab96eb1b7eb70bc5c82fede334bd60df2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16858 CVE: CVE-2026-64556 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 037a3c43edfb597665dd34457cd22b14692f2ba3 ] perf_event_remove_on_exec() removes events by calling perf_event_exit_event(). For top-level events, this removes the event from the context with DETACH_EXIT only. This can leave inconsistent group state when a removed event is a group leader and the group contains siblings without remove_on_exec. If the group was active, the surviving siblings can remain active and attached to the removed leader's sibling list, but are no longer represented by a valid group leader on the PMU context active lists. A later close of the removed leader uses DETACH_GROUP and can promote the still-active siblings from this stale group state. The next schedule-in can then add an already-linked active_list entry again, corrupting the PMU context active list. With DEBUG_LIST enabled, this is caught as a list_add double-add in merge_sched_in(). Fix this by detaching group relationships when remove_on_exec removes an event. This preserves the existing task-exit and revoke behavior, while ensuring surviving siblings are ungrouped before the removed event leaves the context. Fixes: 2e498d0a74e5 ("perf: Add support for event removal on exec") Signed-off-by: Taeyang Lee <0wn(a)theori.io> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://patch.msgid.link/ai65GgZcC0LAlWLG@Taeyangs-MacBook-Pro.local Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index dbfe7f054d4b..6916dc78b0e7 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -4451,7 +4451,8 @@ static void perf_event_enable_on_exec(struct perf_event_context *ctx) static void perf_remove_from_owner(struct perf_event *event); static void perf_event_exit_event(struct perf_event *event, - struct perf_event_context *ctx); + struct perf_event_context *ctx, + unsigned long detach_flags); /* * Removes all events from the current task that have been marked @@ -4478,7 +4479,7 @@ static void perf_event_remove_on_exec(struct perf_event_context *ctx) modified = true; - perf_event_exit_event(event, ctx); + perf_event_exit_event(event, ctx, DETACH_GROUP); } raw_spin_lock_irqsave(&ctx->lock, flags); @@ -13224,10 +13225,11 @@ static void sync_child_event(struct perf_event *child_event) } static void -perf_event_exit_event(struct perf_event *event, struct perf_event_context *ctx) +perf_event_exit_event(struct perf_event *event, + struct perf_event_context *ctx, + unsigned long detach_flags) { struct perf_event *parent_event = event->parent; - unsigned long detach_flags = 0; if (parent_event) { /* @@ -13242,7 +13244,7 @@ perf_event_exit_event(struct perf_event *event, struct perf_event_context *ctx) * Do destroy all inherited groups, we don't care about those * and being thorough is better. */ - detach_flags = DETACH_GROUP | DETACH_CHILD; + detach_flags |= DETACH_GROUP | DETACH_CHILD; mutex_lock(&parent_event->child_mutex); } @@ -13321,7 +13323,7 @@ static void perf_event_exit_task_context(struct task_struct *child) perf_event_task(child, child_ctx, 0); list_for_each_entry_safe(child_event, next, &child_ctx->event_list, event_entry) - perf_event_exit_event(child_event, child_ctx); + perf_event_exit_event(child_event, child_ctx, 0); mutex_unlock(&child_ctx->mutex); -- 2.34.1

2 1

[PATCH OLK-5.10] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
by Zhang Kunbo 29 Jul '26

29 Jul '26

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v6.6.144 commit 48b91ed7e22bb82571c34f8b80b6ecdc90a6fab8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16138 CVE: CVE-2026-63807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ef057cbf825e03b63f6edf5980f96abf3c53089d upstream. When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization. Fixes: 9eba50f8d7fc ("KVM: x86/mmu: Consult max mapping level when zapping collapsible SPTEs") Cc: stable(a)vger.kernel.org Cc: David Matlack <dmatlack(a)google.com> Cc: James Houghton <jthoughton(a)google.com> Cc: Alexander Bulekov <bkov(a)amazon.com> Cc: Fred Griffoul <fgriffo(a)amazon.co.uk> Cc: Alexander Graf <graf(a)amazon.de> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: Filippo Sironi <sironi(a)amazon.de> Cc: Ivan Orlov <iorlov(a)amazon.co.uk> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> conflicts: include/linux/kvm_host.h [context conflicts] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kvm/mmu/mmu.c | 18 ++++++++++++------ include/linux/kvm_host.h | 7 ++++++- 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 6ee54414295b..2d71bcd36eca 100755 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6466,13 +6466,19 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, sp = sptep_to_sp(sptep); /* - * We cannot do huge page mapping for indirect shadow pages, - * which are found on the last rmap (level = 1) when not using - * tdp; such shadow pages are synced with the page table in - * the guest, and the guest page table is using 4K page size - * mapping if the indirect sp has level = 1. + * Direct shadow page can be replaced by a hugepage if the host + * mapping level allows it and the memslot maps all of the host + * hugepage. Note! If the memslot maps only part of the + * hugepage, sp->gfn may be below slot->base_gfn, and querying + * the max mapping level would cause an out-of-bounds lpage_info + * access. So the gfn bounds check *must* be done first. + * + * Indirect shadow pages are created when the guest page tables + * are using 4K pages. Since the host mapping is always + * constrained by the page size in the guest, indirect shadow + * pages are never collapsible. */ - if (sp->role.direct && + if (sp->role.direct && is_gfn_in_memslot(slot, sp->gfn) && sp->role.level < kvm_mmu_max_mapping_level(kvm, slot, sp->gfn, PG_LEVEL_NUM)) { kvm_zap_one_rmap_spte(kvm, rmap_head, sptep); diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 3bf870ffc8b7..783be5bb05c8 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1184,6 +1184,11 @@ int kvm_request_irq_source_id(struct kvm *kvm); void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id); bool kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args); +static inline bool is_gfn_in_memslot(const struct kvm_memory_slot *slot, gfn_t gfn) +{ + return gfn >= slot->base_gfn && gfn < slot->base_gfn + slot->npages; +} + void kire_arch_cached_data_update(struct kvm *kvm, struct kvm_kernel_irq_routing_entry *e); /* @@ -1206,7 +1211,7 @@ try_get_memslot(struct kvm_memslots *slots, int slot_index, gfn_t gfn) slot_index = array_index_nospec(slot_index, slots->used_slots); slot = &slots->memslots[slot_index]; - if (gfn >= slot->base_gfn && gfn < slot->base_gfn + slot->npages) + if (is_gfn_in_memslot(slot, gfn)) return slot; else return NULL; -- 2.34.1

2 1

[PATCH OLK-6.6] drivers/base/memory: fix memory block reference leak in poison accounting
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Muchun Song <songmuchun(a)bytedance.com> stable inclusion from stable-v6.6.142 commit 686b4283f82cd630fafd7ca9b03dfc080b3ec8fa category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16374 CVE: CVE-2026-64182 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 03a2cc1756a0570f887d624cd6c535ea0cbd4951 upstream. memblk_nr_poison_inc() and memblk_nr_poison_sub() look up a memory block via find_memory_block_by_id(), which acquires a reference to the memory block device. Both helpers use the returned memory block without dropping that reference, leaking the device reference on each successful lookup. Drop the reference after updating nr_hwpoison. Link: https://lore.kernel.org/20260428085219.1316047-3-songmuchun@bytedance.com Fixes: 5033091de814 ("mm/hwpoison: introduce per-memory_block hwpoison counter") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com> Acked-by: Oscar Salvador <osalvador(a)suse.de> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: "Huang, Ying" <huang.ying.caritas(a)gmail.com> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: "Rafael J. Wysocki" <rafael(a)kernel.org> Cc: Vishal Verma <vishal.l.verma(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/base/memory.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 32a7bbc00599..2196b53a62f7 100644 --- a/drivers/base/memory.c +++ b/drivers/base/memory.c @@ -1306,8 +1306,10 @@ void memblk_nr_poison_inc(unsigned long pfn) const unsigned long block_id = pfn_to_block_id(pfn); struct memory_block *mem = find_memory_block_by_id(block_id); - if (mem) + if (mem) { atomic_long_inc(&mem->nr_hwpoison); + put_device(&mem->dev); + } } void memblk_nr_poison_sub(unsigned long pfn, long i) @@ -1315,8 +1317,10 @@ void memblk_nr_poison_sub(unsigned long pfn, long i) const unsigned long block_id = pfn_to_block_id(pfn); struct memory_block *mem = find_memory_block_by_id(block_id); - if (mem) + if (mem) { atomic_long_sub(i, &mem->nr_hwpoison); + put_device(&mem->dev); + } } static unsigned long memblk_nr_poison(struct memory_block *mem) -- 2.34.1

2 1

[PATCH OLK-6.6] spi: qup: fix error pointer deref after DMA setup failure
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Johan Hovold <johan(a)kernel.org> stable inclusion from stable-v6.6.142 commit 45760b72e84c1a1498f1a8a9047184c85299da20 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16365 CVE: CVE-2026-64170 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a7e8f3efd50a165ba0189f6dc57f7e51a7d149db ] The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?p… Cc: stable(a)vger.kernel.org # 4.1 Signed-off-by: Johan Hovold <johan(a)kernel.org> Link: https://patch.msgid.link/20260512074334.914735-1-johan@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-qup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index 1e9cd86d9dcc..fd442062847d 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@ -967,8 +967,11 @@ static int spi_qup_init_dma(struct spi_controller *host, resource_size_t base) err: dma_release_channel(host->dma_tx); + host->dma_tx = NULL; err_tx: dma_release_channel(host->dma_rx); + host->dma_rx = NULL; + return ret; } -- 2.34.1

2 1

[PATCH OLK-6.6] i2c: stub: Reject I2C block transfers with invalid length
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Weiming Shi <bestswngs(a)gmail.com> stable inclusion from stable-v6.6.144 commit 1c4ffe6b4f04365485ed58d64c9bb86b46fc9037 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16516 CVE: CVE-2026-64191 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e upstream. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated(). Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei <xmei5(a)asu.edu> Signed-off-by: Weiming Shi <bestswngs(a)gmail.com> Reviewed-by: Jean Delvare <jdelvare(a)suse.de> Signed-off-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/i2c/i2c-stub.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/i2c-stub.c b/drivers/i2c/i2c-stub.c index d642cad219d9..3a2f472dd6b0 100644 --- a/drivers/i2c/i2c-stub.c +++ b/drivers/i2c/i2c-stub.c @@ -214,6 +214,11 @@ static s32 stub_xfer(struct i2c_adapter *adap, u16 addr, unsigned short flags, * We ignore banks here, because banked chips don't use I2C * block transfers */ + if (data->block[0] == 0 || + data->block[0] > I2C_SMBUS_BLOCK_MAX) { + ret = -EINVAL; + break; + } if (data->block[0] > 256 - command) /* Avoid overrun */ data->block[0] = 256 - command; len = data->block[0]; -- 2.34.1

2 1

[PATCH OLK-5.10] spi: qup: fix error pointer deref after DMA setup failure
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Johan Hovold <johan(a)kernel.org> stable inclusion from stable-v5.10.259 commit 0bb3bd442f0bdad3932739a61dd6c580c9c1955e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16365 CVE: CVE-2026-64170 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a7e8f3efd50a165ba0189f6dc57f7e51a7d149db ] The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?p… Cc: stable(a)vger.kernel.org # 4.1 Signed-off-by: Johan Hovold <johan(a)kernel.org> Link: https://patch.msgid.link/20260512074334.914735-1-johan@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/spi/spi-qup.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-qup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index 2cc9bb413c10..5caf347674f0 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@ -969,8 +969,10 @@ static int spi_qup_init_dma(struct spi_master *master, resource_size_t base) err: dma_release_channel(master->dma_tx); + master->dma_tx = NULL; err_tx: dma_release_channel(master->dma_rx); + master->dma_rx = NULL; return ret; } -- 2.34.1

2 1

[PATCH OLK-5.10] i2c: stub: Reject I2C block transfers with invalid length
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Weiming Shi <bestswngs(a)gmail.com> stable inclusion from stable-v5.10.260 commit 7e9072dbd5f2f17934751873450d2c22080ead80 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16516 CVE: CVE-2026-64191 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e upstream. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated(). Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei <xmei5(a)asu.edu> Signed-off-by: Weiming Shi <bestswngs(a)gmail.com> Reviewed-by: Jean Delvare <jdelvare(a)suse.de> Signed-off-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/i2c/i2c-stub.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/i2c-stub.c b/drivers/i2c/i2c-stub.c index 537a598e22db..a8f2251327eb 100644 --- a/drivers/i2c/i2c-stub.c +++ b/drivers/i2c/i2c-stub.c @@ -215,6 +215,11 @@ static s32 stub_xfer(struct i2c_adapter *adap, u16 addr, unsigned short flags, * We ignore banks here, because banked chips don't use I2C * block transfers */ + if (data->block[0] == 0 || + data->block[0] > I2C_SMBUS_BLOCK_MAX) { + ret = -EINVAL; + break; + } if (data->block[0] > 256 - command) /* Avoid overrun */ data->block[0] = 256 - command; len = data->block[0]; -- 2.34.1

2 1

[PATCH OLK-6.6] iov_iter: Fix potential underflow in iov_iter_extract_xarray_pages()
by Chen Jinghuang 29 Jul '26

29 Jul '26

From: David Howells <dhowells(a)redhat.com> mainline inclusion from mainline-v7.2-rc2 commit 55f4bb9373ca4a521f3b0119366db92715a39b81 category: bugfix bugzilla: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… -------------------------------- In iov_iter_extract_xarray_pages(), if no pages are extracted because there's a hole (or something otherwise unextractable) in the xarray, then the calculation of maxsize at the end can go wrong if the starting offset is not zero. Fix this by returning 0 in such a case and freeing the page array if allocated here rather than being passed in. Note that in the near future, ITER_XARRAY should be removed. Fixes: 7d58fe731028 ("iov_iter: Add a function to extract a page list from an iterator") Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Link: https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.c… Signed-off-by: David Howells <dhowells(a)redhat.com> Link: https://patch.msgid.link/20260625140640.3116900-6-dhowells@redhat.com Reviewed-by: Christoph Hellwig <hch(a)lst.de> cc: Paulo Alcantara <pc(a)manguebit.org> cc: Matthew Wilcox <willy(a)infradead.org> cc: Christoph Hellwig <hch(a)infradead.org> cc: Jens Axboe <axboe(a)kernel.dk> cc: Mike Marshall <hubcap(a)omnibond.com> cc: netfs(a)lists.linux.dev cc: linux-fsdevel(a)vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner(a)kernel.org> Conflicts: lib/iov_iter.c [a little context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- lib/iov_iter.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 0b8fc9831225..a4cc8d68b409 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -1625,6 +1625,7 @@ static ssize_t iov_iter_extract_xarray_pages(struct iov_iter *i, struct page *page, **p; unsigned int nr = 0, offset; loff_t pos = i->xarray_start + i->iov_offset; + bool will_alloc = !*pages; pgoff_t index = pos >> PAGE_SHIFT; XA_STATE(xas, i->xarray, index); @@ -1653,6 +1654,14 @@ static ssize_t iov_iter_extract_xarray_pages(struct iov_iter *i, } rcu_read_unlock(); + if (!nr) { + if (will_alloc) { + kvfree(*pages); + *pages = NULL; + } + return 0; + } + maxsize = min_t(size_t, nr * PAGE_SIZE - offset, maxsize); iov_iter_advance(i, maxsize); return maxsize; -- 2.34.1

2 1

[PATCH OLK-6.6] e1000e: Fix out-of-bounds MMIO access by validating BAR0 size
by Pu Lehui 29 Jul '26

29 Jul '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9678 Reference: https://lore.kernel.org/all/20260727025645.2600363-1-pulehui@huaweicloud.com -------------------------------- Syzkaller reported a kernel panic caused by an out-of-bounds MMIO access in the e1000e driver. [ 82.868719][ T404] e1000e 0000:00:02.0: The NVM Checksum Is Not Valid [ 82.872328][ T404] Unable to handle kernel paging request at virtual address ffff80008894e090 [ 83.085218][ T404] CPU: 2 UID: 0 PID: 404 Comm: bash Not tainted 7.2.0-rc2-g3f1f75536668 #1 PREEMPTLAZY [ 83.129013][ T404] pc : e1000_get_cfg_done_82571+0x70/0x158 [ 83.140092][ T404] lr : e1000_get_cfg_done_82571+0x68/0x158 [ 83.151196][ T404] sp : ffff80008ac37410 [ 83.158922][ T404] x29: ffff80008ac37410 x28: ffff0000cd6a11b8 x27: ffff0000c58190d0 [ 83.173919][ T404] x26: ffff0000cd6a11b8 x25: ffff0000cd6a0bc0 x24: ffff0000cd6a0000 [ 83.189417][ T404] x23: 0000000000001010 x22: ffff0000cd6a11c0 x21: ffff0000cd6a11b8 [ 83.205195][ T404] x20: 0000000000000064 x19: ffff80008894e090 x18: 0000000000000000 [ 83.220545][ T404] x17: ffff800081c1a3f4 x16: ffff800081c19c10 x15: ffff800081e86510 [ 83.235764][ T404] x14: 0000000000000001 x13: 0000000000000001 x12: ffff60001bc8a8b3 [ 83.251301][ T404] x11: 1fffe0001bc8a8b2 x10: ffff60001bc8a8b2 x9 : ffff800081eae25c [ 83.266705][ T404] x8 : 00009fffe437574e x7 : ffff0000de454593 x6 : 0000000000000001 [ 83.281919][ T404] x5 : ffff0000cf2b9640 x4 : 0000000000000000 x3 : dfff800000000000 [ 83.297317][ T404] x2 : 0000000000000007 x1 : ffff0000cd6a11c0 x0 : 0000000000000000 [ 83.312601][ T404] Call trace: [ 83.318662][ T404] e1000_get_cfg_done_82571+0x70/0x158 (P) [ 83.329748][ T404] e1000e_phy_hw_reset_generic+0x17c/0x1a8 [ 83.341541][ T404] e1000_probe+0xbd8/0x1988 [ 83.350334][ T404] local_pci_probe+0x84/0x130 Repetition steps: 1. Find PCI device which BAR0 size <= 4K. If it's: Device Addr: 0000:00:02.0 BAR0 SIZE: 4K Vendor/Device ID: 0x1af4 0x1004 2. Unbind the above PCI device echo '0000:00:02.0' > /sys/bus/pci/devices/0000:00:02.0/driver/unbind 3. Set the above device to e1000e new_id echo '1af4 1004' > /sys/bus/pci/drivers/e1000e/new_id During e1000_probe(), the driver maps the device's BAR0 memory region. If the device has a 4K BAR0, ioremap() maps only 4K of space. Later in the probe process, when the NVM checksum validation fails, the driver attempts to perform a hardware reset and falls back to the err_eeprom cleanup path. This cleanup path will trigger an OOB access kernel panic: e1000_phy_hw_reset e1000e_phy_hw_reset_generic e1000_get_cfg_done_82571 er32(EEMNGCTL) readl(hw->hw_addr + EEMNGCTL); <-- EEMNGCTL(0x1010) > 4K, OOB access Fix this by verifying that the MMIO length (pci_resource_len(pdev, 0)) is at least SZ_64K before calling ioremap(). This accounts not only for standard registers up to E1000_SYSSTMPH, but also for flash registers mapped on ICH/PCH chipsets (up to offset 0xE074 / ~57.1 KB). Since PCI BAR sizes are power-of-two aligned, SZ_64K is the minimum valid BAR0 size required to ensure all subsequent MMIO accesses remain strictly within the mapped boundary. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Reviewed-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 3b1d142ebf27..c638c4b42ee8 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7435,6 +7435,12 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) mmio_len = pci_resource_len(pdev, 0); err = -EIO; + /* Smallest BAR0 that covers every register the driver accesses */ + if (mmio_len < SZ_64K) { + dev_err(&pdev->dev, "MMIO len is too small\n"); + goto err_ioremap; + } + adapter->hw.hw_addr = ioremap(mmio_start, mmio_len); if (!adapter->hw.hw_addr) goto err_ioremap; -- 2.34.1

2 1

[PATCH OLK-5.10] e1000e: Fix out-of-bounds MMIO access by validating BAR0 size
by Pu Lehui 29 Jul '26

29 Jul '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9678 Reference: https://lore.kernel.org/all/20260727025645.2600363-1-pulehui@huaweicloud.com -------------------------------- Syzkaller reported a kernel panic caused by an out-of-bounds MMIO access in the e1000e driver. [ 82.868719][ T404] e1000e 0000:00:02.0: The NVM Checksum Is Not Valid [ 82.872328][ T404] Unable to handle kernel paging request at virtual address ffff80008894e090 [ 83.085218][ T404] CPU: 2 UID: 0 PID: 404 Comm: bash Not tainted 7.2.0-rc2-g3f1f75536668 #1 PREEMPTLAZY [ 83.129013][ T404] pc : e1000_get_cfg_done_82571+0x70/0x158 [ 83.140092][ T404] lr : e1000_get_cfg_done_82571+0x68/0x158 [ 83.151196][ T404] sp : ffff80008ac37410 [ 83.158922][ T404] x29: ffff80008ac37410 x28: ffff0000cd6a11b8 x27: ffff0000c58190d0 [ 83.173919][ T404] x26: ffff0000cd6a11b8 x25: ffff0000cd6a0bc0 x24: ffff0000cd6a0000 [ 83.189417][ T404] x23: 0000000000001010 x22: ffff0000cd6a11c0 x21: ffff0000cd6a11b8 [ 83.205195][ T404] x20: 0000000000000064 x19: ffff80008894e090 x18: 0000000000000000 [ 83.220545][ T404] x17: ffff800081c1a3f4 x16: ffff800081c19c10 x15: ffff800081e86510 [ 83.235764][ T404] x14: 0000000000000001 x13: 0000000000000001 x12: ffff60001bc8a8b3 [ 83.251301][ T404] x11: 1fffe0001bc8a8b2 x10: ffff60001bc8a8b2 x9 : ffff800081eae25c [ 83.266705][ T404] x8 : 00009fffe437574e x7 : ffff0000de454593 x6 : 0000000000000001 [ 83.281919][ T404] x5 : ffff0000cf2b9640 x4 : 0000000000000000 x3 : dfff800000000000 [ 83.297317][ T404] x2 : 0000000000000007 x1 : ffff0000cd6a11c0 x0 : 0000000000000000 [ 83.312601][ T404] Call trace: [ 83.318662][ T404] e1000_get_cfg_done_82571+0x70/0x158 (P) [ 83.329748][ T404] e1000e_phy_hw_reset_generic+0x17c/0x1a8 [ 83.341541][ T404] e1000_probe+0xbd8/0x1988 [ 83.350334][ T404] local_pci_probe+0x84/0x130 Repetition steps: 1. Find PCI device which BAR0 size <= 4K. If it's: Device Addr: 0000:00:02.0 BAR0 SIZE: 4K Vendor/Device ID: 0x1af4 0x1004 2. Unbind the above PCI device echo '0000:00:02.0' > /sys/bus/pci/devices/0000:00:02.0/driver/unbind 3. Set the above device to e1000e new_id echo '1af4 1004' > /sys/bus/pci/drivers/e1000e/new_id During e1000_probe(), the driver maps the device's BAR0 memory region. If the device has a 4K BAR0, ioremap() maps only 4K of space. Later in the probe process, when the NVM checksum validation fails, the driver attempts to perform a hardware reset and falls back to the err_eeprom cleanup path. This cleanup path will trigger an OOB access kernel panic: e1000_phy_hw_reset e1000e_phy_hw_reset_generic e1000_get_cfg_done_82571 er32(EEMNGCTL) readl(hw->hw_addr + EEMNGCTL); <-- EEMNGCTL(0x1010) > 4K, OOB access Fix this by verifying that the MMIO length (pci_resource_len(pdev, 0)) is at least SZ_64K before calling ioremap(). This accounts not only for standard registers up to E1000_SYSSTMPH, but also for flash registers mapped on ICH/PCH chipsets (up to offset 0xE074 / ~57.1 KB). Since PCI BAR sizes are power-of-two aligned, SZ_64K is the minimum valid BAR0 size required to ensure all subsequent MMIO accesses remain strictly within the mapped boundary. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Reviewed-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 9e383ce1008e..86a88fe8401d 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7377,6 +7377,12 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) mmio_len = pci_resource_len(pdev, 0); err = -EIO; + /* Smallest BAR0 that covers every register the driver accesses */ + if (mmio_len < SZ_64K) { + dev_err(&pdev->dev, "MMIO len is too small\n"); + goto err_ioremap; + } + adapter->hw.hw_addr = ioremap(mmio_start, mmio_len); if (!adapter->hw.hw_addr) goto err_ioremap; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] e1000e: Fix out-of-bounds MMIO access by validating BAR0 size
by Pu Lehui 29 Jul '26

29 Jul '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9678 Reference: https://lore.kernel.org/all/20260727025645.2600363-1-pulehui@huaweicloud.com -------------------------------- Syzkaller reported a kernel panic caused by an out-of-bounds MMIO access in the e1000e driver. [ 82.868719][ T404] e1000e 0000:00:02.0: The NVM Checksum Is Not Valid [ 82.872328][ T404] Unable to handle kernel paging request at virtual address ffff80008894e090 [ 83.085218][ T404] CPU: 2 UID: 0 PID: 404 Comm: bash Not tainted 7.2.0-rc2-g3f1f75536668 #1 PREEMPTLAZY [ 83.129013][ T404] pc : e1000_get_cfg_done_82571+0x70/0x158 [ 83.140092][ T404] lr : e1000_get_cfg_done_82571+0x68/0x158 [ 83.151196][ T404] sp : ffff80008ac37410 [ 83.158922][ T404] x29: ffff80008ac37410 x28: ffff0000cd6a11b8 x27: ffff0000c58190d0 [ 83.173919][ T404] x26: ffff0000cd6a11b8 x25: ffff0000cd6a0bc0 x24: ffff0000cd6a0000 [ 83.189417][ T404] x23: 0000000000001010 x22: ffff0000cd6a11c0 x21: ffff0000cd6a11b8 [ 83.205195][ T404] x20: 0000000000000064 x19: ffff80008894e090 x18: 0000000000000000 [ 83.220545][ T404] x17: ffff800081c1a3f4 x16: ffff800081c19c10 x15: ffff800081e86510 [ 83.235764][ T404] x14: 0000000000000001 x13: 0000000000000001 x12: ffff60001bc8a8b3 [ 83.251301][ T404] x11: 1fffe0001bc8a8b2 x10: ffff60001bc8a8b2 x9 : ffff800081eae25c [ 83.266705][ T404] x8 : 00009fffe437574e x7 : ffff0000de454593 x6 : 0000000000000001 [ 83.281919][ T404] x5 : ffff0000cf2b9640 x4 : 0000000000000000 x3 : dfff800000000000 [ 83.297317][ T404] x2 : 0000000000000007 x1 : ffff0000cd6a11c0 x0 : 0000000000000000 [ 83.312601][ T404] Call trace: [ 83.318662][ T404] e1000_get_cfg_done_82571+0x70/0x158 (P) [ 83.329748][ T404] e1000e_phy_hw_reset_generic+0x17c/0x1a8 [ 83.341541][ T404] e1000_probe+0xbd8/0x1988 [ 83.350334][ T404] local_pci_probe+0x84/0x130 Repetition steps: 1. Find PCI device which BAR0 size <= 4K. If it's: Device Addr: 0000:00:02.0 BAR0 SIZE: 4K Vendor/Device ID: 0x1af4 0x1004 2. Unbind the above PCI device echo '0000:00:02.0' > /sys/bus/pci/devices/0000:00:02.0/driver/unbind 3. Set the above device to e1000e new_id echo '1af4 1004' > /sys/bus/pci/drivers/e1000e/new_id During e1000_probe(), the driver maps the device's BAR0 memory region. If the device has a 4K BAR0, ioremap() maps only 4K of space. Later in the probe process, when the NVM checksum validation fails, the driver attempts to perform a hardware reset and falls back to the err_eeprom cleanup path. This cleanup path will trigger an OOB access kernel panic: e1000_phy_hw_reset e1000e_phy_hw_reset_generic e1000_get_cfg_done_82571 er32(EEMNGCTL) readl(hw->hw_addr + EEMNGCTL); <-- EEMNGCTL(0x1010) > 4K, OOB access Fix this by verifying that the MMIO length (pci_resource_len(pdev, 0)) is at least SZ_64K before calling ioremap(). This accounts not only for standard registers up to E1000_SYSSTMPH, but also for flash registers mapped on ICH/PCH chipsets (up to offset 0xE074 / ~57.1 KB). Since PCI BAR sizes are power-of-two aligned, SZ_64K is the minimum valid BAR0 size required to ensure all subsequent MMIO accesses remain strictly within the mapped boundary. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Reviewed-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 7583f893ef6e..4801b7dcdfee 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7112,6 +7112,12 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) mmio_len = pci_resource_len(pdev, 0); err = -EIO; + /* Smallest BAR0 that covers every register the driver accesses */ + if (mmio_len < SZ_64K) { + dev_err(&pdev->dev, "MMIO len is too small\n"); + goto err_ioremap; + } + adapter->hw.hw_addr = ioremap(mmio_start, mmio_len); if (!adapter->hw.hw_addr) goto err_ioremap; -- 2.34.1

2 1

[PATCH OLK-6.6] smb: client: fix change notify replay double-free
by Lai Zewei 29 Jul '26

29 Jul '26

mainline inclusion from mainline-v7.2-rc1 commit 145f820dcbb2cced374f2532f8a61a44dce4a615 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9675 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable(a)vger.kernel.org Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/smb/client/smb2pdu.c [ctx conflicts] Signed-off-by: Lai Zewei <laizewei3(a)huawei.com> --- fs/smb/client/smb2pdu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 6c12f696122f..367c414195d4 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -4021,6 +4021,8 @@ SMB2_change_notify(const unsigned int xid, struct cifs_tcon *tcon, replay_again: /* reinitialize for possible replay */ + resp_buftype = CIFS_NO_BUFFER; + memset(&rsp_iov, 0, sizeof(rsp_iov)); flags = 0; server = cifs_pick_channel(ses); -- 2.52.0

2 13

[PATCH OLK-6.6 0/2] Fix CVE-2026-64448
by Zizhi Wo 28 Jul '26

28 Jul '26

Fix CVE-2026-64448 Shoichiro Miyamoto (2): smb: client: restrict implied bcc[0] exemption to responses without data area smb: client: reject overlapping data areas in SMB2 responses fs/smb/client/smb2misc.c | 52 +++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 8 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6 V2 0/4] Fix CVE-2026-64378
by Zizhi Wo 28 Jul '26

28 Jul '26

Fix CVE-2026-64378 Baokun Li (2): writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() writeback: drop now-unnecessary rcu_barrier() in cgroup_writeback_umount() Jan Kara (2): writeback: Avoid contention on wb->list_lock when switching inodes writeback: Fix use after free in inode_switch_wbs_work_fn() fs/fs-writeback.c | 134 +++++++++++++++++++++---------- include/linux/backing-dev-defs.h | 15 +++- include/linux/writeback.h | 2 + mm/backing-dev.c | 25 ++++++ 4 files changed, 134 insertions(+), 42 deletions(-) -- 2.52.0

2 5

[PATCH OLK-6.6 00/32] backport minios patches from linux mainline
by Qinxin Xia 28 Jul '26

28 Jul '26

From: Hongye Lin <linhongye(a)h-partners.com> driver inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/8904 ---------------------------------------------------------------------- backport minios patches from linux mainline Marc Zyngier (2): KVM: arm64: Properly save/restore HCRX_EL2 KVM: arm64: Kill HCRX_HOST_FLAGS Mark Brown (18): arm64/sysreg: Add definition for ID_AA64PFR2_EL1 arm64/sysreg: Add definition for ID_AA64ISAR3_EL1 arm64/sysreg: Add definition for ID_AA64FPFR0_EL1 arm64/sysreg: Add definition for FPMR arm64/sysreg: Add EnFPM field for SCTLR_EL1 and HCRX_EL2 arm64/sysreg: Add LUT field for ID_AA64ISAR2_EL1 arm64/cpufeature: Hook new identification registers up to cpufeature arm64/hwcap: Define hwcaps for 2023 DPISA features kselftest/arm64: Add basic FPMR test kselftest/arm64: Handle FPMR context in generic signal frame parser kselftest/arm64: Add 2023 DPISA hwcap test coverage arm64/signal: Add FPMR signal handling arm64/ptrace: Expose FPMR via ptrace arm64/hwcap: Add support for FEAT_CMPBR arm64/sysreg: Update ID_AA64ISAR2_EL1 for FEAT_CMPBR arm64/fpsimd: Support FEAT_FPMR arm64/fpsimd: Don't corrupt FPMR when streaming mode changes arm64/fpsimd: Enable host kernel access to FPMR Mark Rutland (7): arm64/fpsimd: Add fpsimd_save_and_flush_current_state() arm64/fpsimd: signal32: Always save+flush state early arm64/fpsimd: signal: Always save+flush state early arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR arm64/fpsimd: Reset FPMR upon exec() arm64/fpsimd: Do not discard modified SVE state arm64/fpsimd: Avoid warning when sve_to_fpsimd() is unused Qinxin Xia (4): arm64: Kconfig: Detect toolchain support for LSUI arm64: cpufeature: add FEAT_LSUI Add support "arm64.nocnp" for start option arm64: syscall: switch to fpsimd_syscall_enter() Yifan Wu (1): kselftest/arm64: Add FEAT_CMPBR to the hwcap selftest Documentation/arch/arm64/elf_hwcaps.rst | 30 +++++ arch/arm64/Kconfig | 5 + arch/arm64/include/asm/cpu.h | 3 + arch/arm64/include/asm/cpufeature.h | 6 + arch/arm64/include/asm/el2_setup.h | 2 +- arch/arm64/include/asm/fpsimd.h | 7 +- arch/arm64/include/asm/hwcap.h | 10 ++ arch/arm64/include/asm/kvm_arm.h | 1 - arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/include/asm/processor.h | 4 + arch/arm64/include/asm/signal_common.h | 20 ++- arch/arm64/include/uapi/asm/hwcap.h | 10 ++ arch/arm64/include/uapi/asm/sigcontext.h | 8 ++ arch/arm64/kernel/cpufeature.c | 70 +++++++++- arch/arm64/kernel/cpuinfo.c | 3 + arch/arm64/kernel/entry-common.c | 50 +++++-- arch/arm64/kernel/fpsimd.c | 74 +++++------ arch/arm64/kernel/hwcap_str.h | 10 ++ arch/arm64/kernel/idreg-override.c | 11 ++ arch/arm64/kernel/ptrace.c | 44 +++++++ arch/arm64/kernel/signal.c | 102 ++++++++------- arch/arm64/kernel/signal32.c | 11 +- arch/arm64/kvm/fpsimd.c | 1 + arch/arm64/kvm/hyp/include/hyp/switch.h | 12 +- arch/arm64/tools/cpucaps | 4 +- arch/arm64/tools/sysreg | 122 +++++++++++++++++- include/uapi/linux/elf.h | 1 + tools/testing/selftests/arm64/abi/hwcap.c | 116 +++++++++++++++++ .../testing/selftests/arm64/signal/.gitignore | 1 + .../arm64/signal/testcases/fpmr_siginfo.c | 82 ++++++++++++ .../arm64/signal/testcases/testcases.c | 8 ++ .../arm64/signal/testcases/testcases.h | 1 + 32 files changed, 710 insertions(+), 120 deletions(-) create mode 100644 tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c -- 2.33.0

3 35

[PATCH v3 OLK-5.10 00/15] Fix CVE-2026-46054
by Cai Xinchen 28 Jul '26

28 Jul '26

v2->v3: Fix lsm: add backing_file LSM hooks in ovl_mmap when security_mmap_backing_file failed, fput realfile but not set vma->vm_file to original user_file. v1->v2: Add commit 9fe595fad54d ("selinux: fix incorrect execmem checks on overlayfs") ovl_open_realfile reletion code feature patch ("ovl: pass layer mnt to ovl_open_realfile: ovl_open_realfile reletion.") init_file code refactoring patch ("fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers") backing_file structure and backing_file_open function reletion features: patch ("fs: use backing_file container for internal files with "fake" f_path") patch ("fs: move cleanup from init_file() into its callers") bpf_fd_pass const warning fix patch ("lsm: constify the 'file' parameter in security_binder_transfer_file()") code refactoring: store real path instead of fake path in backing file f_path patch ("fs: get mnt_writers count for an open backing file's real path") patch ("fs: create helper file_user_path() for user displayed mapped file path") patch ("fs: store real path instead of fake path in backing file f_path") patch ("ovl: Fix nested backing file paths") patch ("perf/core: Fix MMAP event path names with backing files") backing_file const warning fix patch ("fs: constify file ptr in backing_file accessor helpers") SELinux overlay backing_file mmap/mprotect check prepare for lsm function: patch ("fs: prepare for adding LSM blob to backing_file") patch ("lsm: add backing_file LSM hooks") CVE-2026-46054 fix: Add SELinux lsm hooks for backing_file mmap/mprotect patch ("selinux: fix overlayfs mmap() and mprotect() access checks") bugfix commit 9fe595fad54d ("selinux: fix incorrect execmem checks on overlayfs") to fix mount check PROCESS__EXEC to the mounter Adrian Hunter (1): perf/core: Fix MMAP event path names with backing files Amir Goldstein (9): [Backport] ovl: pass layer mnt to ovl_open_realfile() fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers fs: use backing_file container for internal files with "fake" f_path fs: move cleanup from init_file() into its callers fs: get mnt_writers count for an open backing file's real path fs: create helper file_user_path() for user displayed mapped file path fs: store real path instead of fake path in backing file f_path fs: constify file ptr in backing_file accessor helpers fs: prepare for adding LSM blob to backing_file André Almeida (1): ovl: Fix nested backing file paths Khadija Kamran (1): lsm: constify the 'file' parameter in security_binder_transfer_file() Ondrej Mosnacek (1): selinux: fix incorrect execmem checks on overlayfs Paul Moore (2): lsm: add backing_file LSM hooks selinux: fix overlayfs mmap() and mprotect() access checks arch/arc/kernel/troubleshoot.c | 6 +- fs/file_table.c | 139 +++++++++++++--- fs/internal.h | 18 ++- fs/open.c | 76 ++++++--- fs/overlayfs/file.c | 35 ++-- fs/overlayfs/overlayfs.h | 1 + fs/overlayfs/super.c | 16 +- fs/overlayfs/util.c | 14 ++ fs/proc/base.c | 2 +- fs/proc/nommu.c | 2 +- fs/proc/task_mmu.c | 4 +- fs/proc/task_nommu.c | 2 +- include/linux/fs.h | 44 ++++- include/linux/lsm_audit.h | 2 +- include/linux/lsm_hook_defs.h | 7 +- include/linux/lsm_hooks.h | 1 + include/linux/security.h | 26 ++- kernel/events/core.c | 2 +- kernel/trace/trace_output.c | 2 +- security/security.c | 112 ++++++++++++- security/selinux/hooks.c | 256 ++++++++++++++++++++++-------- security/selinux/include/objsec.h | 11 ++ 22 files changed, 638 insertions(+), 140 deletions(-) -- 2.18.0.huawei.25

2 16

[PATCH openEuler-1.0-LTS] drm/amd/display: Validate GPIO pin LUT table size before iterating
by Fanhua Li 28 Jul '26

28 Jul '26

From: Harry Wentland <harry.wentland(a)amd.com> stable inclusion from stable-v6.6.142 commit fb30a3890d62fd50a95aef684faf64a307592e42 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16453 CVE: CVE-2026-64097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream. [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Signed-off-by: Ivan Lipski <ivan.lipski(a)amd.com> Tested-by: Dan Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c [Fanhua Li: context conflict] Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c index eab007e1793c2..827d22b73fbcb 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c @@ -446,6 +446,10 @@ static enum bp_result get_gpio_i2c_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + table_index = record->i2c_id & I2C_HW_LANE_MUX; if (count < table_index) { @@ -705,6 +709,11 @@ static enum bp_result bios_parser_get_gpio_pin_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); #endif + + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + for (i = 0; i < count; ++i) { if (header->gpio_pin[i].gpio_id != gpio_id) continue; -- 2.43.0

2 1

[PATCH OLK-6.6] cgroup/rstat: avoid disabling irqs for O(num_cpu)
by Cai Xinchen 28 Jul '26

28 Jul '26

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.15-rc1 commit 0efc297a3c4974dbd609ee36fc6345720b6ca735 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9112 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- cgroup_rstat_flush_locked() grabs the irq safe cgroup_rstat_lock while iterating all possible cpus. It only drops the lock if there is scheduler or spin lock contention. If neither, then interrupts can be disabled for a long time. On large machines this can disable interrupts for a long enough time to drop network packets. On 400+ CPU machines I've seen interrupt disabled for over 40 msec. Prevent rstat from disabling interrupts while processing all possible cpus. Instead drop and reacquire cgroup_rstat_lock for each cpu. This approach was previously discussed in https://lore.kernel.org/lkml/ZBz%2FV5a7%2F6PZeM7S@slm.duckdns.org/, though this was in the context of an non-irq rstat spin lock. Benchmark this change with: 1) a single stat_reader process with 400 threads, each reading a test memcg's memory.stat repeatedly for 10 seconds. 2) 400 memory hog processes running in the test memcg and repeatedly charging memory until oom killed. Then they repeat charging and oom killing. v6.14-rc6 with CONFIG_IRQSOFF_TRACER with stat_reader and hogs, finds interrupts are disabled by rstat for 45341 usec: # => started at: _raw_spin_lock_irq # => ended at: cgroup_rstat_flush # # # _------=> CPU# # / _-----=> irqs-off/BH-disabled # | / _----=> need-resched # || / _---=> hardirq/softirq # ||| / _--=> preempt-depth # |||| / _-=> migrate-disable # ||||| / delay # cmd pid |||||| time | caller # \ / |||||| \ | / stat_rea-96532 52d.... 0us*: _raw_spin_lock_irq stat_rea-96532 52d.... 45342us : cgroup_rstat_flush stat_rea-96532 52d.... 45342us : tracer_hardirqs_on <-cgroup_rstat_flush stat_rea-96532 52d.... 45343us : <stack trace> => memcg1_stat_format => memory_stat_format => memory_stat_show => seq_read_iter => vfs_read => ksys_read => do_syscall_64 => entry_SYSCALL_64_after_hwframe With this patch the CONFIG_IRQSOFF_TRACER doesn't find rstat to be the longest holder. The longest irqs-off holder has irqs disabled for 4142 usec, a huge reduction from previous 45341 usec rstat finding. Running stat_reader memory.stat reader for 10 seconds: - without memory hogs: 9.84M accesses => 12.7M accesses - with memory hogs: 9.46M accesses => 11.1M accesses The throughput of memory.stat access improves. The mode of memory.stat access latency after grouping by of 2 buckets: - without memory hogs: 64 usec => 16 usec - with memory hogs: 64 usec => 8 usec The memory.stat latency improves. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Greg Thelen <gthelen(a)google.com> Tested-by: Greg Thelen <gthelen(a)google.com> Acked-by: Michal Koutný <mkoutny(a)suse.com> Reviewed-by: Yosry Ahmed <yosry.ahmed(a)linux.dev> Signed-off-by: Tejun Heo <tj(a)kernel.org> Conflicts: kernel/cgroup/rstat.c [Use spin_(un)lock_irq instead of __cgroup_rstat_(un)lock in 6.6] Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- kernel/cgroup/rstat.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c index b589868cc85c..ea5a21dc9df3 100644 --- a/kernel/cgroup/rstat.c +++ b/kernel/cgroup/rstat.c @@ -205,12 +205,10 @@ static void cgroup_rstat_flush_locked(struct cgroup *cgrp) raw_spin_unlock_irqrestore(cpu_lock, flags); /* play nice and yield if necessary */ - if (need_resched() || spin_needbreak(&cgroup_rstat_lock)) { - spin_unlock_irq(&cgroup_rstat_lock); - if (!cond_resched()) - cpu_relax(); - spin_lock_irq(&cgroup_rstat_lock); - } + spin_unlock_irq(&cgroup_rstat_lock); + if (!cond_resched()) + cpu_relax(); + spin_lock_irq(&cgroup_rstat_lock); } } -- 2.18.0.huawei.25

2 1

[PATCH OLK-5.10 0/2] nfs: fix invalidate dentries on transient errors
by Long Li 28 Jul '26

28 Jul '26

This patch set fix invalidate dentries on transient errors. Scott Mayhew (1): nfs: don't invalidate dentries on transient errors Trond Myklebust (1): NFS: Trace lookup revalidation failure fs/nfs/dir.c | 44 ++++++++++++++++++-------------------------- 1 file changed, 18 insertions(+), 26 deletions(-) -- 2.52.0

2 3

[PATCH openEuler-1.0-LTS] drm/amd/display: Validate GPIO pin LUT table size before iterating
by Fanhua Li 28 Jul '26

28 Jul '26

From: Harry Wentland <harry.wentland(a)amd.com> stable inclusion from stable-v6.6.142 commit fb30a3890d62fd50a95aef684faf64a307592e42 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16453 CVE: CVE-2026-64097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream. [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Signed-off-by: Ivan Lipski <ivan.lipski(a)amd.com> Tested-by: Dan Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflict: drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c [Fanhua Li: context conflict] Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c index eab007e1793c2..827d22b73fbcb 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c @@ -446,6 +446,10 @@ static enum bp_result get_gpio_i2c_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + table_index = record->i2c_id & I2C_HW_LANE_MUX; if (count < table_index) { @@ -705,6 +709,11 @@ static enum bp_result bios_parser_get_gpio_pin_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); #endif + + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + for (i = 0; i < count; ++i) { if (header->gpio_pin[i].gpio_id != gpio_id) continue; -- 2.43.0

2 1

[PATCH OLK-5.10] drm/amd/display: Validate GPIO pin LUT table size before iterating
by Fanhua Li 28 Jul '26

28 Jul '26

From: Harry Wentland <harry.wentland(a)amd.com> stable inclusion from stable-v6.6.142 commit fb30a3890d62fd50a95aef684faf64a307592e42 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16453 CVE: CVE-2026-64097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream. [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Signed-off-by: Ivan Lipski <ivan.lipski(a)amd.com> Tested-by: Dan Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c [Fanhua Li: context conflict] Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c index 9dd41eaf32cb5..2f6c49af7f8e3 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c @@ -380,6 +380,10 @@ static enum bp_result get_gpio_i2c_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + pin = (struct atom_gpio_pin_assignment *) header->gpio_pin; for (table_index = 0; table_index < count; table_index++) { @@ -535,6 +539,11 @@ static enum bp_result bios_parser_get_gpio_pin_info( - sizeof(struct atom_common_table_header)) / sizeof(struct atom_gpio_pin_assignment); #endif + + if (!bios_get_image(&bp->base, DATA_TABLES(gpio_pin_lut), + le16_to_cpu(header->table_header.structuresize))) + return BP_RESULT_BADBIOSTABLE; + for (i = 0; i < count; ++i) { if (header->gpio_pin[i].gpio_id != gpio_id) continue; -- 2.43.0

2 1

[PATCH OLK-6.6] ftrace: Add global mutex to serialize trace_parser access
by Tengda Wu 27 Jul '26

27 Jul '26

From: Tengda Wu <wutengda(a)huaweicloud.com> mainline inclusion from mainline-v7.2-rc5 commit 7720b63bcef3f54c7fe288774b720a227d54a306 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state. Fixes: e704eff3ff51 ("ftrace: Have set_graph_function handle multiple functions in one write") Fixes: 689fd8b65d66 ("tracing: trace parser support for function and graph") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260725024721.1983675-1-wutengda@huaweicloud.com Signed-off-by: Tengda Wu <wutengda(a)huaweicloud.com> Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/ftrace.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 94f7ed57d43e..a575c1237420 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1067,6 +1067,12 @@ struct ftrace_ops global_ops = { FTRACE_OPS_FL_PID, }; +/* + * parser_lock - Protects trace_parser state against concurrent operations. + * Held across trace_get_user() and subsequent buffer parsing to prevent races. + */ +static DEFINE_MUTEX(parser_lock); + /* * Used by the stack unwinder to know about dynamic ftrace trampolines. */ @@ -5202,6 +5208,8 @@ ftrace_regex_write(struct file *file, const char __user *ubuf, /* iter->hash is a local copy, so we don't need regex_lock */ parser = &iter->parser; + + guard(mutex)(&parser_lock); read = trace_get_user(parser, ubuf, cnt, ppos); if (read >= 0 && trace_parser_loaded(parser) && @@ -5927,12 +5935,14 @@ int ftrace_regex_release(struct inode *inode, struct file *file) iter = file->private_data; parser = &iter->parser; + mutex_lock(&parser_lock); if (trace_parser_loaded(parser)) { int enable = !(iter->flags & FTRACE_ITER_NOTRACE); ftrace_process_regex(iter, parser->buffer, parser->idx, enable); } + mutex_unlock(&parser_lock); trace_parser_put(parser); @@ -6264,10 +6274,12 @@ ftrace_graph_release(struct inode *inode, struct file *file) parser = &fgd->parser; + mutex_lock(&parser_lock); if (trace_parser_loaded((parser))) { ret = ftrace_graph_set_hash(fgd->new_hash, parser->buffer); } + mutex_unlock(&parser_lock); trace_parser_put(parser); @@ -6387,6 +6399,7 @@ ftrace_graph_write(struct file *file, const char __user *ubuf, parser = &fgd->parser; + guard(mutex)(&parser_lock); read = trace_get_user(parser, ubuf, cnt, ppos); if (read >= 0 && trace_parser_loaded(parser) && -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2026-64378
by Zizhi Wo 27 Jul '26

27 Jul '26

Fix CVE-2026-64378 Baokun Li (1): writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() Tejun Heo (1): writeback, cgroup: inode_switch_wbs() shouldn't give up on wb_switch_rwsem trylock fail fs/fs-writeback.c | 38 ++++++++++++++++++++++++-------------- 1 file changed, 24 insertions(+), 14 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6 0/4] Fix CVE-2026-64378
by Zizhi Wo 27 Jul '26

27 Jul '26

Fix CVE-2026-64378 Baokun Li (2): writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() writeback: drop now-unnecessary rcu_barrier() in cgroup_writeback_umount() Jan Kara (2): writeback: Avoid contention on wb->list_lock when switching inodes writeback: Fix use after free in inode_switch_wbs_work_fn() fs/fs-writeback.c | 133 +++++++++++++++++++++---------- include/linux/backing-dev-defs.h | 4 + include/linux/writeback.h | 2 + mm/backing-dev.c | 5 ++ 4 files changed, 103 insertions(+), 41 deletions(-) -- 2.52.0

2 5