Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
cdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement. However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed. So it doesn't seem as simple as just reverting through an offset of msg_iter. 3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached. Additi
return an error, and the returned length is the same as the input length parameter, even if some data is cached. Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; ''' So it's ok to just return 'copied' without error when a "cork" situation occurs. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/328cac3f9f8ae394748485e769a527518a9137c8 - https://git.kernel.org/stable/c/2e36a81d388ec9c3f78b6223f7eda2088cd40adb - https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7 - https://git.kernel.org/stable/c/6
88cd40adb - https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7 - https://git.kernel.org/stable/c/603943f022a7fe5cc83ca7005faf34798fb7853f - https://git.kernel.org/stable/c/54a3ecaeeeae8176da8badbd7d72af1017032c39
CVE ID: CVE-2025-38167 State: PUBLISHED Published: 2025-07-03T08:36:06.987Z Last Updated: 2025-11-03T17:34:56.803Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: handle hdr_first_de() return value The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst
nts where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5390b3d4c6d41d05bb9149d094d504cbc9ea85bf - https://git.kernel.org/stable/c/83cd0aa74793384dbdffc140500b200e9776a302 - https://git.kernel.org/stable/c/701340a25b1ad210e6b8192195be21fd3fcc22c7 - https://git.kernel.org/stable/c/2d5879f64554181b89f44d4817b9ea86e8e913e1 - https://git.kernel.org/stable/c/4ecd0cde89feee26525ccdf1af0c1ae156ca010b - https://git.kernel.org/stable/c/af5cab0e5b6f8edb0be51a9f47f3f620e0b4fd70
CVE ID: CVE-2025-38168 State: PUBLISHED Published: 2025-07-03T08:36:07.620Z Last Updated: 2025-07-28T04:14:03.385Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf: arm-ni: Unregister PMUs on probe failure When a resource allocation fails in one clock domain of an NI device, we need to properly roll back all previously registered perf PMUs in other clock domains of the same device. Otherwise, it can lead to kernel panics. Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374 arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000 arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16 list_add corruption: next->prev
U region 0x1f3c13000 arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16 list_add corruption: next->prev should be prev (fffffd01e9698a18), but was 0000000000000000. (next=ffff10001a0decc8). pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : list_add_valid_or_report+0x7c/0xb8 lr : list_add_valid_or_report+0x7c/0xb8 Call trace: __list_add_valid_or_report+0x7c/0xb8 perf_pmu_register+0x22c/0x3a0 arm_ni_probe+0x554/0x70c [arm_ni] platform_probe+0x70/0xe8 really_probe+0xc6/0x4d8 driver_probe_device+0x48/0x170 __driver_attach+0x8e/0x1c0 bus_for_each_dev+0x64/0xf0 driver_add+0x138/0x260 bus_add_driver+0x68/0x138 __platform_driver_register+0x2c/0x40 arm_ni_init+0x14/0
h_dev+0x64/0xf0 driver_add+0x138/0x260 bus_add_driver+0x68/0x138 __platform_driver_register+0x2c/0x40 arm_ni_init+0x14/0x2a [arm_ni] do_init_module+0x36/0x298 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception SMP: stopping secondary CPUs References: - https://git.kernel.org/stable/c/7e958e116e3be05a1f869b5a885fc5d674c7725f - https://git.kernel.org/stable/c/72caf9886e9c1731cf7bfe3eabc308b9268b21d6 - https://git.kernel.org/stable/c/7f57afde6a44d9e044885e1125034edd4fda02e8
CVE ID: CVE-2025-38169 State: PUBLISHED Published: 2025-07-03T08:36:08.393Z Last Updated: 2025-07-28T04:14:09.744Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP On system with SME, a thread's kernel FPSIMD state may be erroneously clobbered during a context switch immediately after that state is restored. Systems without SME are unaffected. If the CPU happens to be in streaming SVE mode before a context switch to a thread with kernel FPSIMD state, fpsimd_thread_switch() will restore the kernel FPSIMD state using fpsimd_load_kernel_state() while the CPU is still in
fpsimd_thread_switch() will restore the kernel FPSIMD state using fpsimd_load_kernel_state() while the CPU is still in streaming SVE mode. When fpsimd_thread_switch() subsequently calls fpsimd_flush_cpu_state(), this will execute an SMSTOP, causing an exit from streaming SVE mode. The exit from streaming SVE mode will cause the hardware to reset a number of FPSIMD/SVE/SME registers, clobbering the FPSIMD state. Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel FPSIMD state. References: - https://git.kernel.org/stable/c/55d52af498daea75aa03ba9b7e444c8ae495ac20 - https://git.kernel.org/stable/c/a305821f597ec943849d3e53924adb88c61ed682 - https://git.kernel.org/stable/c/0
ae495ac20 - https://git.kernel.org/stable/c/a305821f597ec943849d3e53924adb88c61ed682 - https://git.kernel.org/stable/c/01098d893fa8a6edb2b56e178b798e3e6b674f02
CVE ID: CVE-2025-38170 State: PUBLISHED Published: 2025-07-03T08:36:09.012Z Last Updated: 2025-11-03T17:34:57.733Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Discard stale CPU state when handling SME traps The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps
e_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted;
SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | /
from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ] Addi
emory prior to a return to userspace. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/de89368de3894a8db27caeb8fd902ba1c49f696a - https://git.kernel.org/stable/c/43be952e885476dafb74aa832c0847b2f4f650c6 - https://git.kernel.org/stable/c/6103f9ba51a59afb5a0f32299c837377c5a5a693 - https://git.kernel.org/stable/c/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3 - https://git.kernel.org/stable/c/d3eaab3c70905c5467e5c4ea403053d67505adeb
CVE ID: CVE-2025-38171 State: PUBLISHED Published: 2025-07-03T08:36:09.651Z Last Updated: 2025-07-28T04:14:12.480Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: power: supply: max77705: Fix workqueue error handling in probe The create_singlethread_workqueue() doesn't return error pointers, it returns NULL. Also cleanup the workqueue on the error paths. References: - https://git.kernel.org/stable/c/7f16be2b2927fdcfe40b596b7411c46d23a82034 - https://git.kernel.org/stable/c/11741b8e382d34b13277497ab91123d8b0b5c2db
CVE ID: CVE-2025-38172 State: PUBLISHED Published: 2025-07-03T08:36:10.334Z Last Updated: 2025-07-28T04:14:13.860Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: erofs: avoid using multiple devices with different type For multiple devices, both primary and extra devices should be the same type. `erofs_init_device` has already guaranteed that if the primary is a file-backed device, extra devices should also be regular files. However, if the primary is a block device while the extra device is a file-backed device, `erofs_init_device` will get an ENOTBLK, which is not treated as an error in `erofs_fc_get_tree`, and that leads to a
e, `erofs_init_device` will get an ENOTBLK, which is not treated as an error in `erofs_fc_get_tree`, and that leads to an UAF: erofs_fc_get_tree get_tree_bdev_flags(erofs_fc_fill_super) erofs_read_superblock erofs_init_device // sbi->dif0 is not inited yet, // return -ENOTBLK deactivate_locked_super free(sbi) if (err is -ENOTBLK) sbi->dif0.file = filp_open() // sbi UAF So if -ENOTBLK is hitted in `erofs_init_device`, it means the primary device must be a block device, and the extra device is not a block device. The error can be converted to -EINVAL. References: - https://git.kernel.org/stable/c/65115472f741ca000d7ea4a5922214f93cd1516e - https://git.kernel.org/stable/c/cd04beb9ce2773a16057248
t.kernel.org/stable/c/65115472f741ca000d7ea4a5922214f93cd1516e - https://git.kernel.org/stable/c/cd04beb9ce2773a16057248bb4fa424068ae3807 - https://git.kernel.org/stable/c/9748f2f54f66743ac77275c34886a9f890e18409
CVE ID: CVE-2025-38173 State: PUBLISHED Published: 2025-07-03T08:36:10.969Z Last Updated: 2025-11-03T17:34:59.620Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/32d3e8049a8b60f18c5c39f5931bfb1130ac11c9 - https://git.kernel.org/stable/c/c064ae2881d839709bd72d484d5f2af157f46024 - https://git.kernel.org/stable/c/e1cc69da619588b1488689fe3535a0ba75a2b0e7 - https://git.kernel.org/stable/c/78ea1ff6cb413
https://git.kernel.org/stable/c/e1cc69da619588b1488689fe3535a0ba75a2b0e7 - https://git.kernel.org/stable/c/78ea1ff6cb413a03ff6f7af4e28e24b4461a0965 - https://git.kernel.org/stable/c/5e9666ac8b94c978690f937d59170c5237bd2c45 - https://git.kernel.org/stable/c/7894694b5d5b2ecfd7fb081d6f60b9e169ab4d13 - https://git.kernel.org/stable/c/c9610dda42bd382a96f97e68825cb5f66cd9e1dc - https://git.kernel.org/stable/c/8a4e047c6cc07676f637608a9dd675349b5de0a7
CVE ID: CVE-2025-38174 State: PUBLISHED Published: 2025-07-04T10:39:55.732Z Last Updated: 2025-11-03T17:35:01.586Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Do not double dequeue a configuration request Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: <TASK> ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x
fg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request(). Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122). Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e49e994cd83705f7ca30e
. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e49e994cd83705f7ca30eda1e304abddfd96a37a - https://git.kernel.org/stable/c/0a3011d47dbc92a33621861c423cb64833d7fe57 - https://git.kernel.org/stable/c/2f62eda4d974c26bc595425eafd429067541f2c9 - https://git.kernel.org/stable/c/85286e634ebbaf9c0fb1cdf580add2f33fc7628c - https://git.kernel.org/stable/c/5a057f261539720165d03d85024da2b52e67f63d - https://git.kernel.org/stable/c/eb2d5e794fb966b3ef8bde99eb8561446a53509f - https://git.kernel.org/stable/c/0771bcbe2f6e5d5f263cf466efe571d2754a46da - https://git.kernel.org/stable/c/cdb4feab2f39e75a66239e3a112beced279612a8 - https://git.kernel.org/stable/c/0
2754a46da - https://git.kernel.org/stable/c/cdb4feab2f39e75a66239e3a112beced279612a8 - https://git.kernel.org/stable/c/0f73628e9da1ee39daf5f188190cdbaee5e0c98c
CVE ID: CVE-2025-38175 State: PUBLISHED Published: 2025-07-04T10:39:56.392Z Last Updated: 2025-07-28T04:14:17.635Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: binder: fix yet another UAF in binder_devices Commit e77aff5528a18 ("binderfs: fix use-after-free in binder_devices") addressed a use-after-free where devices could be released without first being removed from the binder_devices list. However, there is a similar path in binder_free_proc() that was missed: ================================================================== BUG: KASAN: slab-use-after-free in binder_remove_device+0xd4/0x100 Write of size 8 at addr ffff0000
==================== BUG: KASAN: slab-use-after-free in binder_remove_device+0xd4/0x100 Write of size 8 at addr ffff0000c773b900 by task umount/467 CPU: 12 UID: 0 PID: 467 Comm: umount Not tainted 6.15.0-rc7-00138-g57483a362741 #9 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_remove_device+0xd4/0x100 binderfs_evict_inode+0x230/0x2f0 evict+0x25c/0x5dc iput+0x304/0x480 dentry_unlink_inode+0x208/0x46c __dentry_kill+0x154/0x530 [...] Allocated by task 463: __kmalloc_cache_noprof+0x13c/0x324 binderfs_binder_device_create.isra.0+0x138/0xa60 binder_ctl_ioctl+0x1ac/0x230 [...] Freed by task 215: kfree+0x184/0x31c binder_proc_dec_tmpref+0x33c/0x4ac binder_deferred_func+0xc10/0x1108
c/0x230 [...] Freed by task 215: kfree+0x184/0x31c binder_proc_dec_tmpref+0x33c/0x4ac binder_deferred_func+0xc10/0x1108 process_one_work+0x520/0xba4 [...] ================================================================== Call binder_remove_device() within binder_free_proc() to ensure the device is removed from the binder_devices list before being kfreed. References: - https://git.kernel.org/stable/c/4a7694f499cae5b83412c5281bf2c961f34f2ed6 - https://git.kernel.org/stable/c/72a726fb5f25fbb31d6060acfb671c1955831245 - https://git.kernel.org/stable/c/9857af0fcff385c75433f2162c30c62eb912ef6d
CVE ID: CVE-2025-38176 State: PUBLISHED Published: 2025-07-04T10:39:57.229Z Last Updated: 2025-07-28T04:14:19.060Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in binderfs_evict_inode() Running 'stress-ng --binderfs 16 --timeout 300' under KASAN-enabled kernel, I've noticed the following: BUG: KASAN: slab-use-after-free in binderfs_evict_inode+0x1de/0x2d0 Write of size 8 at addr ffff88807379bc08 by task stress-ng-binde/1699 CPU: 0 UID: 0 PID: 1699 Comm: stress-ng-binde Not tainted 6.14.0-rc7-g586de92313fc-dirty #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
6.14.0-rc7-g586de92313fc-dirty #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x1c2/0x2a0 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __virt_addr_valid+0x18c/0x540 ? __virt_addr_valid+0x469/0x540 print_report+0x155/0x840 ? __virt_addr_valid+0x18c/0x540 ? __virt_addr_valid+0x469/0x540 ? __phys_addr+0xba/0x170 ? binderfs_evict_inode+0x1de/0x2d0 kasan_report+0x147/0x180 ? binderfs_evict_inode+0x1de/0x2d0 binderfs_evict_inode+0x1de/0x2d0 ? __pfx_binderfs_evict_inode+0x10/0x10 evict+0x524/0x9f0 ? __pfx_lock_release+0x10/0x10 ? __pfx_evict+0x10/0x10 ? do_raw_spin_unlock+0x4d/
vict_inode+0x10/0x10 evict+0x524/0x9f0 ? __pfx_lock_release+0x10/0x10 ? __pfx_evict+0x10/0x10 ? do_raw_spin_unlock+0x4d/0x210 ? _raw_spin_unlock+0x28/0x50 ? iput+0x697/0x9b0 __dentry_kill+0x209/0x660 ? shrink_kill+0x8d/0x2c0 shrink_kill+0xa9/0x2c0 shrink_dentry_list+0x2e0/0x5e0 shrink_dcache_parent+0xa2/0x2c0 ? __pfx_shrink_dcache_parent+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 do_one_tree+0x23/0xe0 shrink_dcache_for_umount+0xa0/0x170 generic_shutdown_super+0x67/0x390 kill_litter_super+0x76/0xb0 binderfs_kill_super+0x44/0x90 deactivate_locked_super+0xb9/0x130 cleanup_mnt+0x422/0x4c0 ? lockdep_hardirqs_on+0x9d/0x150 task_work_run+0x1d2/0x260 ? __pfx_task_wor
ked_super+0xb9/0x130 cleanup_mnt+0x422/0x4c0 ? lockdep_hardirqs_on+0x9d/0x150 task_work_run+0x1d2/0x260 ? __pfx_task_work_run+0x10/0x10 resume_user_mode_work+0x52/0x60 syscall_exit_to_user_mode+0x9a/0x120 do_syscall_64+0x103/0x210 ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0xcac57b Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 RSP: 002b:00007ffecf4226a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 RAX: 0000000000000000 RBX: 00007ffecf422720 RCX: 0000000000cac57b RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffecf422850 RBP: 00007ffecf422850 R08: 0000000028d06ab1 R09:
ac57b RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffecf422850 RBP: 00007ffecf422850 R08: 0000000028d06ab1 R09: 7fffffffffffffff R10: 3fffffffffffffff R11: 0000000000000246 R12: 00007ffecf422718 R13: 00007ffecf422710 R14: 00007f478f87b658 R15: 00007ffecf422830 </TASK> Allocated by task 1705: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x213/0x3e0 binderfs_binder_device_create+0x183/0xa80 binder_ctl_ioctl+0x138/0x190 __x64_sys_ioctl+0x120/0x1b0 do_syscall_64+0xf6/0x210 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1705: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x46/0x50 __kasan_slab_free+0x62/0x70 kfree+0x194/0x440 evict+0x524/0x9f0 do_
_save_track+0x3e/0x80 kasan_save_free_info+0x46/0x50 __kasan_slab_free+0x62/0x70 kfree+0x194/0x440 evict+0x524/0x9f0 do_unlinkat+0x390/0x5b0 __x64_sys_unlink+0x47/0x50 do_syscall_64+0xf6/0x210 entry_SYSCALL_64_after_hwframe+0x77/0x7f This 'stress-ng' workload causes the concurrent deletions from 'binder_devices' and so requires full-featured synchronization to prevent list corruption. I've found this issue independently but pretty sure that syzbot did the same, so Reported-by: and Closes: should be applicable here as well. References: - https://git.kernel.org/stable/c/80ed8ab8efa0d18c03968a2321154f10e2d1a2e3 - https://git.kernel.org/stable/c/aea61a1a77613d4184d7ebe7c1d7cb606458b43b - https:/
ab8efa0d18c03968a2321154f10e2d1a2e3 - https://git.kernel.org/stable/c/aea61a1a77613d4184d7ebe7c1d7cb606458b43b - https://git.kernel.org/stable/c/8c0a559825281764061a127632e5ad273f0466ad
CVE ID: CVE-2025-38177 State: PUBLISHED Published: 2025-07-04T12:47:09.127Z Last Updated: 2025-11-03T19:58:30.487Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sch_hfsc: make hfsc_qlen_notify() idempotent hfsc_qlen_notify() is not idempotent either and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life: 1. update_vf() decreases cl->cl_nactive, so we can check whether it is non-zero before calling it. 2. eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe. Additional Analyst Notes: - CV
es RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9a5fd5c2f4d4afdd5e405083ee53e0789ce76956 - https://git.kernel.org/stable/c/72c61ffbeeb8c50f6d4d70c65d3283aa1bac57a7 - https://git.kernel.org/stable/c/a5efc95a33bd4fcb879250852828cc58c7862970 - https://git.kernel.org/stable/c/0475c85426b18eccdcb7f9fb58d8f8e9c6c58c87 - https://git.kernel.org/stable/c/9030a91235ae4845ec71902c3e0cecfc9ed1f2df - https://git.kernel.org/stable/c/d06476714d2819b550e0cc39222347e2c8941c9d - https://git.kernel.org/stable/c/c1175c4ad01dbc9c979d099861fa90a754f72059 - https://git.kernel.o
e0cc39222347e2c8941c9d - https://git.kernel.org/stable/c/c1175c4ad01dbc9c979d099861fa90a754f72059 - https://git.kernel.org/stable/c/51eb3b65544c9efd6a1026889ee5fb5aa62da3bb
CVE ID: CVE-2025-38178 State: REJECTED Published: 2025-07-04T13:37:06.717Z Last Updated: 2025-07-28T04:32:02.009Z Description: No description available.
CVE ID: CVE-2025-38179 State: PUBLISHED Published: 2025-07-04T13:37:07.383Z Last Updated: 2025-07-28T04:14:20.383Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: fix max_sge overflow in smb_extract_folioq_to_rdma() This fixes the following problem: [ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30 [ 750.346409] [ T9870] ================================================================== [ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870 [ 750.347705] [ T9870] [ 750.348077] [ T9870