- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()
by Xinyu Zheng 18 Dec '25

18 Dec '25

From: Guangshuo Li <lgs201920130244(a)gmail.com> stable inclusion from stable-v6.12.58 commit 35f3fb86bb0158a298d6834e7e110dcaf07f490c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IDDEV5 CVE: CVE-2025-68190 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit cc9a8e238e42c1f43b98c097995137d644b69245 ] kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference. Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/gpu/drm/amd/amdgpu/atom.c [context conflict] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/atom.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c index 4cfc786699c7..b3acfc943184 100644 --- a/drivers/gpu/drm/amd/amdgpu/atom.c +++ b/drivers/gpu/drm/amd/amdgpu/atom.c @@ -1225,10 +1225,15 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index, ectx.ps = params; ectx.abort = false; ectx.last_jump = 0; - if (ws) + if (ws) { ectx.ws = kcalloc(4, ws, GFP_KERNEL); - else + if (!ectx.ws) { + ret = -ENOMEM; + goto free; + } + } else { ectx.ws = NULL; + } debug_depth++; while (1) { -- 2.34.1

2 1

[PATCH OLK-6.6] xsched: move xsched types to user-accessible headers
by Liu Kai 18 Dec '25

18 Dec '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID9IFI ----------------------------------------- Fix xsched syscall compilation by resolving declaration conflicts and ensuring user-space access to parameter types. - Move include/linux/xsched_types.h -> include/uapi/linux/xsched for user-space visibility - Move include/uapi/linux/xcu_vstream.h -> include/uapi/linux/xsched - Fixes errors: "conflicting types" and "struct not visible" Fixes: 832cfa264d7c ("xsched: add xsched_{set,get}attr syscall") Signed-off-by: Liu Kai <liukai284(a)huawei.com> --- include/linux/sched.h | 2 +- include/linux/vstream.h | 2 +- include/linux/xcu_group.h | 2 +- include/linux/xsched.h | 4 ++-- .../xsched_types.h => uapi/linux/xsched/types.h} | 14 ++++++++------ include/uapi/linux/{ => xsched}/xcu_vstream.h | 6 +++--- init/init_task.c | 2 +- 7 files changed, 17 insertions(+), 15 deletions(-) rename include/{linux/xsched_types.h => uapi/linux/xsched/types.h} (59%) rename include/uapi/linux/{ => xsched}/xcu_vstream.h (92%) diff --git a/include/linux/sched.h b/include/linux/sched.h index bb23790fd2d3..321abdc384da 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -42,7 +42,7 @@ #include <linux/kabi.h> #ifdef CONFIG_XCU_SCHEDULER -#include <linux/xsched_types.h> +#include <uapi/linux/xsched/types.h> #endif /* task_struct member predeclarations (sorted alphabetically): */ diff --git a/include/linux/vstream.h b/include/linux/vstream.h index 7d99e416624f..227bbf77085e 100644 --- a/include/linux/vstream.h +++ b/include/linux/vstream.h @@ -2,7 +2,7 @@ #ifndef _LINUX_VSTREAM_H #define _LINUX_VSTREAM_H -#include <uapi/linux/xcu_vstream.h> +#include <uapi/linux/xsched/xcu_vstream.h> #include <linux/ktime.h> #define MAX_VSTREAM_SIZE 2048 diff --git a/include/linux/xcu_group.h b/include/linux/xcu_group.h index c129dca32c51..d7d6972e7f5c 100644 --- a/include/linux/xcu_group.h +++ b/include/linux/xcu_group.h @@ -3,7 +3,7 @@ #define __XSCHED_XCU_GROUP_H__ #include <linux/idr.h> -#include <uapi/linux/xcu_vstream.h> +#include <uapi/linux/xsched/xcu_vstream.h> #ifndef CONFIG_XSCHED_NR_CUS #define CONFIG_XSCHED_NR_CUS 128 diff --git a/include/linux/xsched.h b/include/linux/xsched.h index 46fe6ae2bc77..86b248a18f97 100644 --- a/include/linux/xsched.h +++ b/include/linux/xsched.h @@ -4,10 +4,10 @@ #include <linux/cgroup.h> #include <linux/kref.h> +#include <linux/math64.h> #include <linux/vstream.h> #include <linux/xcu_group.h> -#include <linux/xsched_types.h> -#include <linux/math64.h> +#include <uapi/linux/xsched/types.h> #define XSCHED_LOG_PREFIX "XSched" #define XSCHED_INFO(fmt, ...) \ diff --git a/include/linux/xsched_types.h b/include/uapi/linux/xsched/types.h similarity index 59% rename from include/linux/xsched_types.h rename to include/uapi/linux/xsched/types.h index f52fe32d5198..e5f11a2973e8 100644 --- a/include/linux/xsched_types.h +++ b/include/uapi/linux/xsched/types.h @@ -1,13 +1,15 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef _XSCHED_TYPE_H -#define _XSCHED_TYPE_H +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_LINUX_XSCHED_TYPES_H +#define _UAPI_LINUX_XSCHED_TYPES_H + +#include <linux/types.h> struct xsched_attr { /* Scheduling class type, from enum xcu_sched_class */ - unsigned int xsched_class; + __u32 xsched_class; /* RT scheduling priority, from enum xse_prio */ - unsigned int xsched_priority; + __u32 xsched_priority; }; enum xcu_sched_class { @@ -24,4 +26,4 @@ enum xse_prio { XSE_PRIO_DFLT = XSE_PRIO_LOW }; -#endif /* ! _XSCHED_TYPE_H */ +#endif /* _UAPI_LINUX_XSCHED_TYPES_H */ diff --git a/include/uapi/linux/xcu_vstream.h b/include/uapi/linux/xsched/xcu_vstream.h similarity index 92% rename from include/uapi/linux/xcu_vstream.h rename to include/uapi/linux/xsched/xcu_vstream.h index b60c0e0e15f5..4b3abf386a1c 100644 --- a/include/uapi/linux/xcu_vstream.h +++ b/include/uapi/linux/xsched/xcu_vstream.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef _UAPI_XCU_VSTREAM_H -#define _UAPI_XCU_VSTREAM_H +#ifndef _UAPI_LINUX_XSCHED_XCU_VSTREAM_H +#define _UAPI_LINUX_XSCHED_XCU_VSTREAM_H #include <linux/types.h> @@ -74,4 +74,4 @@ typedef struct vstream_args { KABI_RESERVE_BYTES(2, 8); } vstream_args_t; -#endif /* _UAPI_LINUX_SCHED_H */ +#endif /* _UAPI_LINUX_XSCHED_XCU_VSTREAM_H */ diff --git a/init/init_task.c b/init/init_task.c index 61a6345708c8..9fd44251b8b7 100644 --- a/init/init_task.c +++ b/init/init_task.c @@ -15,7 +15,7 @@ #include <linux/uaccess.h> #ifdef CONFIG_XCU_SCHEDULER -#include <linux/xsched_types.h> +#include <uapi/linux/xsched/types.h> #endif static struct signal_struct init_signals = { -- 2.34.1

2 1

[PATCH OLK-5.10] locking/rwsem: Optimize down_read_trylock() under highly contended case
by Tengda Wu 18 Dec '25

18 Dec '25

From: Muchun Song <songmuchun(a)bytedance.com> mainline inclusion from mainline-v5.16-rc3 commit 14c24048841151548a3f4d9e218510c844c1b737 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IDE51T Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- We found that a process with 10 thousnads threads has been encountered a regression problem from Linux-v4.14 to Linux-v5.4. It is a kind of workload which will concurrently allocate lots of memory in different threads sometimes. In this case, we will see the down_read_trylock() with a high hotspot. Therefore, we suppose that rwsem has a regression at least since Linux-v5.4. In order to easily debug this problem, we write a simply benchmark to create the similar situation lile the following. ```c++ #include <sys/mman.h> #include <sys/time.h> #include <sys/resource.h> #include <sched.h> #include <cstdio> #include <cassert> #include <thread> #include <vector> #include <chrono> volatile int mutex; void trigger(int cpu, char* ptr, std::size_t sz) { cpu_set_t set; CPU_ZERO(&set); CPU_SET(cpu, &set); assert(pthread_setaffinity_np(pthread_self(), sizeof(set), &set) == 0); while (mutex); for (std::size_t i = 0; i < sz; i += 4096) { *ptr = '\0'; ptr += 4096; } } int main(int argc, char* argv[]) { std::size_t sz = 100; if (argc > 1) sz = atoi(argv[1]); auto nproc = std::thread::hardware_concurrency(); std::vector<std::thread> thr; sz <<= 30; auto* ptr = mmap(nullptr, sz, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0); assert(ptr != MAP_FAILED); char* cptr = static_cast<char*>(ptr); auto run = sz / nproc; run = (run >> 12) << 12; mutex = 1; for (auto i = 0U; i < nproc; ++i) { thr.emplace_back(std::thread([i, cptr, run]() { trigger(i, cptr, run); })); cptr += run; } rusage usage_start; getrusage(RUSAGE_SELF, &usage_start); auto start = std::chrono::system_clock::now(); mutex = 0; for (auto& t : thr) t.join(); rusage usage_end; getrusage(RUSAGE_SELF, &usage_end); auto end = std::chrono::system_clock::now(); timeval utime; timeval stime; timersub(&usage_end.ru_utime, &usage_start.ru_utime, &utime); timersub(&usage_end.ru_stime, &usage_start.ru_stime, &stime); printf("usr: %ld.%06ld\n", utime.tv_sec, utime.tv_usec); printf("sys: %ld.%06ld\n", stime.tv_sec, stime.tv_usec); printf("real: %lu\n", std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count()); return 0; } ``` The functionality of above program is simply which creates `nproc` threads and each of them are trying to touch memory (trigger page fault) on different CPU. Then we will see the similar profile by `perf top`. 25.55% [kernel] [k] down_read_trylock 14.78% [kernel] [k] handle_mm_fault 13.45% [kernel] [k] up_read 8.61% [kernel] [k] clear_page_erms 3.89% [kernel] [k] __do_page_fault The highest hot instruction, which accounts for about 92%, in down_read_trylock() is cmpxchg like the following. 91.89 │ lock cmpxchg %rdx,(%rdi) Sice the problem is found by migrating from Linux-v4.14 to Linux-v5.4, so we easily found that the commit ddb20d1d3aed ("locking/rwsem: Optimize down_read_trylock()") caused the regression. The reason is that the commit assumes the rwsem is not contended at all. But it is not always true for mmap lock which could be contended with thousands threads. So most threads almost need to run at least 2 times of "cmpxchg" to acquire the lock. The overhead of atomic operation is higher than non-atomic instructions, which caused the regression. By using the above benchmark, the real executing time on a x86-64 system before and after the patch were: Before Patch After Patch # of Threads real real reduced by ------------ ------ ------ ---------- 1 65,373 65,206 ~0.0% 4 15,467 15,378 ~0.5% 40 6,214 5,528 ~11.0% For the uncontended case, the new down_read_trylock() is the same as before. For the contended cases, the new down_read_trylock() is faster than before. The more contended, the more fast. Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Waiman Long <longman(a)redhat.com> Link: https://lore.kernel.org/r/20211118094455.9068-1-songmuchun@bytedance.com Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/locking/rwsem.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c index cc5cc889b5b7..e32587c141a1 100644 --- a/kernel/locking/rwsem.c +++ b/kernel/locking/rwsem.c @@ -1375,17 +1375,14 @@ static inline int __down_read_trylock(struct rw_semaphore *sem) DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem); - /* - * Optimize for the case when the rwsem is not locked at all. - */ - tmp = RWSEM_UNLOCKED_VALUE; - do { + tmp = atomic_long_read(&sem->count); + while (!(tmp & RWSEM_READ_FAILED_MASK)) { if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp, - tmp + RWSEM_READER_BIAS)) { + tmp + RWSEM_READER_BIAS)) { rwsem_set_reader_owned(sem); return 1; } - } while (!(tmp & RWSEM_READ_FAILED_MASK)); + } return 0; } -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 4e9c55920995d70b3e88b60c69753df54b03fdf4
by kernel test robot 18 Dec '25

18 Dec '25

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 4e9c55920995d70b3e88b60c69753df54b03fdf4 !19703 ppp: associate skb with a device at tx elapsed time: 1467m configs tested: 36 configs skipped: 10 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-15.1.0 arm64 allnoconfig gcc-15.1.0 arm64 defconfig gcc-15.1.0 arm64 randconfig-001-20251218 gcc-5.5.0 arm64 randconfig-002-20251218 gcc-10.5.0 arm64 randconfig-003-20251218 gcc-14.3.0 arm64 randconfig-004-20251218 gcc-5.5.0 x86_64 allmodconfig clang-22 x86_64 allnoconfig clang-22 x86_64 allyesconfig clang-22 x86_64 buildonly-randconfig-001-20251218 gcc-14 x86_64 buildonly-randconfig-002-20251218 gcc-14 x86_64 buildonly-randconfig-003-20251218 clang-22 x86_64 buildonly-randconfig-004-20251218 gcc-14 x86_64 buildonly-randconfig-005-20251218 gcc-14 x86_64 buildonly-randconfig-006-20251218 gcc-14 x86_64 defconfig gcc-14 x86_64 randconfig-001-20251218 clang-22 x86_64 randconfig-002-20251218 clang-22 x86_64 randconfig-003-20251218 clang-22 x86_64 randconfig-004-20251218 clang-22 x86_64 randconfig-005-20251218 clang-22 x86_64 randconfig-006-20251218 clang-22 x86_64 randconfig-011-20251218 gcc-14 x86_64 randconfig-012-20251218 gcc-14 x86_64 randconfig-013-20251218 clang-22 x86_64 randconfig-014-20251218 gcc-12 x86_64 randconfig-015-20251218 gcc-14 x86_64 randconfig-016-20251218 gcc-14 x86_64 randconfig-071-20251218 gcc-14 x86_64 randconfig-072-20251218 gcc-14 x86_64 randconfig-073-20251218 gcc-12 x86_64 randconfig-074-20251218 clang-22 x86_64 randconfig-075-20251218 gcc-12 x86_64 randconfig-076-20251218 clang-22 x86_64 rhel-9.4-rust clang-22 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] timers: Fix NULL function pointer race in timer_shutdown_sync()
by Jinjie Ruan 18 Dec '25

18 Dec '25

From: Yipeng Zou <zouyipeng(a)huawei.com> stable inclusion from stable-v6.6.118 commit 6665fbd7730b26d770c232b20d1b907e6a67a914 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEZ3 CVE: CVE-2025-68214 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20739af07383e6eb1ec59dcd70b72ebfa9ac362c upstream. There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 63a8ce7177dd..4a2aeaa85af3 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1413,10 +1413,11 @@ static int __try_to_del_timer_sync(struct timer_list *timer, bool shutdown) base = lock_timer_base(timer, &flags); - if (base->running_timer != timer) + if (base->running_timer != timer) { ret = detach_if_pending(timer, base, true); - if (shutdown) - timer->function = NULL; + if (shutdown) + timer->function = NULL; + } raw_spin_unlock_irqrestore(&base->lock, flags); -- 2.34.1

2 1

[PATCH OLK-5.10] timers: Fix NULL function pointer race in timer_shutdown_sync()
by Jinjie Ruan 18 Dec '25

18 Dec '25

From: Yipeng Zou <zouyipeng(a)huawei.com> stable inclusion from stable-v6.6.118 commit 6665fbd7730b26d770c232b20d1b907e6a67a914 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEZ3 CVE: CVE-2025-68214 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20739af07383e6eb1ec59dcd70b72ebfa9ac362c upstream. There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index c1b52dab3951..472c97733b2b 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1374,10 +1374,11 @@ static int __try_to_del_timer_sync(struct timer_list *timer, bool shutdown) base = lock_timer_base(timer, &flags); - if (base->running_timer != timer) + if (base->running_timer != timer) { ret = detach_if_pending(timer, base, true); - if (shutdown) - timer->function = NULL; + if (shutdown) + timer->function = NULL; + } raw_spin_unlock_irqrestore(&base->lock, flags); -- 2.34.1

2 1

[PATCH OLK-6.6] usb: storage: Fix memory leak in USB bulk transport
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Desnes Nunes <desnesn(a)redhat.com> stable inclusion from stable-v6.6.119 commit cb1401b5bcc2feb5b038fc4b512e5968b016e05e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDF46 CVE: CVE-2025-68288 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 41e99fe2005182139b1058db71f0d241f8f0078c upstream. A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") Cc: stable <stable(a)kernel.org> Signed-off-by: Desnes Nunes <desnesn(a)redhat.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://patch.msgid.link/20251031043436.55929-1-desnesn@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/usb/storage/transport.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c index 7449e379077a..f79b449d0f11 100644 --- a/drivers/usb/storage/transport.c +++ b/drivers/usb/storage/transport.c @@ -1204,7 +1204,23 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us) US_BULK_CS_WRAP_LEN && bcs->Signature == cpu_to_le32(US_BULK_CS_SIGN)) { + unsigned char buf[US_BULK_CS_WRAP_LEN]; + usb_stor_dbg(us, "Device skipped data phase\n"); + + /* + * Devices skipping data phase might leave CSW data in srb's + * transfer buffer. Zero it to prevent USB protocol leakage. + */ + sg = NULL; + offset = 0; + memset(buf, 0, sizeof(buf)); + if (usb_stor_access_xfer_buf(buf, + US_BULK_CS_WRAP_LEN, srb, &sg, + &offset, TO_XFER_BUF) != + US_BULK_CS_WRAP_LEN) + usb_stor_dbg(us, "Failed to clear CSW data\n"); + scsi_set_resid(srb, transfer_length); goto skipped_data_phase; } -- 2.52.0

2 1

[PATCH OLK-5.10] usb: storage: Fix memory leak in USB bulk transport
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Desnes Nunes <desnesn(a)redhat.com> stable inclusion from stable-v5.10.247 commit 83f0241959831586d9b6d47f6bd5d3dec8f43bf0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDF46 CVE: CVE-2025-68288 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 41e99fe2005182139b1058db71f0d241f8f0078c upstream. A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") Cc: stable <stable(a)kernel.org> Signed-off-by: Desnes Nunes <desnesn(a)redhat.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://patch.msgid.link/20251031043436.55929-1-desnesn@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/usb/storage/transport.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c index 7cc8813f5d8c..9e24d51c3297 100644 --- a/drivers/usb/storage/transport.c +++ b/drivers/usb/storage/transport.c @@ -1199,7 +1199,23 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us) US_BULK_CS_WRAP_LEN && bcs->Signature == cpu_to_le32(US_BULK_CS_SIGN)) { + unsigned char buf[US_BULK_CS_WRAP_LEN]; + usb_stor_dbg(us, "Device skipped data phase\n"); + + /* + * Devices skipping data phase might leave CSW data in srb's + * transfer buffer. Zero it to prevent USB protocol leakage. + */ + sg = NULL; + offset = 0; + memset(buf, 0, sizeof(buf)); + if (usb_stor_access_xfer_buf(buf, + US_BULK_CS_WRAP_LEN, srb, &sg, + &offset, TO_XFER_BUF) != + US_BULK_CS_WRAP_LEN) + usb_stor_dbg(us, "Failed to clear CSW data\n"); + scsi_set_resid(srb, transfer_length); goto skipped_data_phase; } -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> mainline inclusion from mainline-v6.18-rc7 commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEZL CVE: CVE-2025-68229 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable(a)vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Allen Pais <apais(a)linux.microsoft.com> Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linu… Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/target/loopback/tcm_loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c index bc8918f382e4..f7c611a1a530 100644 --- a/drivers/target/loopback/tcm_loop.c +++ b/drivers/target/loopback/tcm_loop.c @@ -963,6 +963,9 @@ static ssize_t tcm_loop_tpg_address_show(struct config_item *item, struct tcm_loop_tpg, tl_se_tpg); struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + if (!tl_hba->sh) + return -ENODEV; + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", tl_hba->sh->host_no, tl_tpg->tl_tpgt); } -- 2.52.0

2 1

[PATCH OLK-6.6] scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> stable inclusion from stable-v6.6.118 commit a6ef60898ddaf1414592ce3e5b0d94276d631663 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEZL CVE: CVE-2025-68229 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc upstream. If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable(a)vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Allen Pais <apais(a)linux.microsoft.com> Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linu… Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/target/loopback/tcm_loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c index 4ec99a55ac30..db13c6a379d8 100644 --- a/drivers/target/loopback/tcm_loop.c +++ b/drivers/target/loopback/tcm_loop.c @@ -893,6 +893,9 @@ static ssize_t tcm_loop_tpg_address_show(struct config_item *item, struct tcm_loop_tpg, tl_se_tpg); struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + if (!tl_hba->sh) + return -ENODEV; + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", tl_hba->sh->host_no, tl_tpg->tl_tpgt); } -- 2.52.0

2 1