Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ist_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553 f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588 f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706 f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677 writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903 __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974 wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081 wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback fs/fs-
back+0x3da/0xa00 fs/fs-writeback.c:2081 wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback fs/fs-writeback.c:2239 [inline] wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266 process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299 worker_thread+0xa60/0x1260 kernel/workqueue.c:2446 kthread+0x26d/0x300 kernel/kthread.c:386 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Allocated by task 298: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/
lab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768 slab_alloc_node mm/slub.c:3421 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484 __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80 fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_l
ow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80 fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_last fs/namei.c:2454 [inline] path_lookupat+0x16d/0x450 fs/namei.c:2478 filename_lookup+0x251/0x600 fs/namei.c:2507 vfs_statx+0x107/0x4b0 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3434 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by t
mon.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 0: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516 ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249 kasan_slab_free include/linux/kasan.h:178 [inline] slab_free_hook mm/slub.c:1745 [inline] slab_free_freelist_hook mm/slub.c:1771 [inline] slab_free mm/slub.c:3686 [inline] kmem_cache_free+0x ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/37e78cad7e9e025e6
ed--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/37e78cad7e9e025e63bb35bc200f44637b009bb1 - https://git.kernel.org/stable/c/4dcd830c420f2190ae32f03626039fde7b57b2ad - https://git.kernel.org/stable/c/1edf68272b8cba2b2817ef1488ecb9f0f84cb6a0 - https://git.kernel.org/stable/c/917ae5e280bc263f56c83fba0d0f0be2c4828083 - https://git.kernel.org/stable/c/3d37cadaac1a8e108e576297aab9125b24ea2dfe - https://git.kernel.org/stable/c/dea243f58a8391e76f42ad5eb59ff210519ee772 - https://git.kernel.org/stable/c/a4b0cc9e0bba7525a29f37714e88df12a47997a2 - https://git.kernel.org/stable/c/6cac47af39b2b8edbb41d47c3bd9c332f83e9932 - https://git.kernel.org/stable
8df12a47997a2 - https://git.kernel.org/stable/c/6cac47af39b2b8edbb41d47c3bd9c332f83e9932 - https://git.kernel.org/stable/c/7c30d79930132466f5be7d0b57add14d1a016bda
CVE ID: CVE-2025-38579 State: PUBLISHED Published: 2025-08-19T17:03:02.308Z Last Updated: 2025-11-03T17:40:08.639Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix KMSAN uninit-value in extent_info usage KMSAN reported a use of uninitialized value in `__is_extent_mergeable()` and `__is_back_mergeable()` via the read extent tree path. The root cause is that `get_read_extent_info()` only initializes three fields (`fofs`, `blk`, `len`) of `struct extent_info`, leaving the remaining fields uninitialized. This leads to undefined behavior when those fields are accessed later, especially during extent merging. Fix it by zero-i
his leads to undefined behavior when those fields are accessed later, especially during extent merging. Fix it by zero-initializing the `extent_info` struct before population. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/08e8ab00a6d20d5544c932ee85a297d833895141 - https://git.kernel.org/stable/c/e68b751ec2b15d866967812c57cfdfc1eba6a269 - https://git.kernel.org/stable/c/dabfa3952c8e6bfe6414dbf32e8b6c5f349dc898 - https://git.kernel.org/stable/c/44a79437309e0ee2276ac17aaedc71253af253a8 - https://git.kernel.org/stable/c/cc1615d5aba4f396cf412579928539a2b124c8a0 - https://git.kernel.org/stable/c/01b6f5955e0008af6bc3a181310d2744bb349800 - https://g
5aba4f396cf412579928539a2b124c8a0 - https://git.kernel.org/stable/c/01b6f5955e0008af6bc3a181310d2744bb349800 - https://git.kernel.org/stable/c/154467f4ad033473e5c903a03e7b9bca7df9a0fa
CVE ID: CVE-2025-38580 State: PUBLISHED Published: 2025-08-19T17:03:03.018Z Last Updated: 2025-09-29T05:54:11.419Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix inode use after free in ext4_end_io_rsv_work() In ext4_io_end_defer_completion(), check if io_end->list_vec is empty to avoid adding an io_end that requires no conversion to the i_rsv_conversion_list, which in turn prevents starting an unnecessary worker. An ext4_emergency_state() check is also added to avoid attempting to abort the journal in an emergency state. Additionally, ext4_put_io_end_defer() is refactored to call ext4_io_end_defer_completion() direct
in an emergency state. Additionally, ext4_put_io_end_defer() is refactored to call ext4_io_end_defer_completion() directly instead of being open-coded. This also prevents starting an unnecessary worker when EXT4_IO_END_FAILED is set but data_err=abort is not enabled. This ensures that the check in ext4_put_io_end_defer() is consistent with the check in ext4_end_bio(). Otherwise, we might add an io_end to the i_rsv_conversion_list and then call ext4_finish_bio(), after which the inode could be freed before ext4_end_io_rsv_work() is called, triggering a use-after-free issue. References: - https://git.kernel.org/stable/c/ac999862b98a0f49e858e509f776be51406f1e77 - https://git.kernel.org/stable/c
References: - https://git.kernel.org/stable/c/ac999862b98a0f49e858e509f776be51406f1e77 - https://git.kernel.org/stable/c/469c44e66e2110054949609dde095788320139d0 - https://git.kernel.org/stable/c/c678bdc998754589cea2e6afab9401d7d8312ac4
CVE ID: CVE-2025-38581 State: PUBLISHED Published: 2025-08-19T17:03:03.718Z Last Updated: 2025-11-03T17:40:10.652Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix crash when rebind ccp device for ccp.ko When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226
78026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x23
05.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [
o_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a25ab6dfa0ce323ec308966988be6b675eb9d3e5 - https://git.kernel.org/stable/c/ce63a
nces: - https://git.kernel.org/stable/c/a25ab6dfa0ce323ec308966988be6b675eb9d3e5 - https://git.kernel.org/stable/c/ce63a83925964ab7564bd216bd92b80bc365492e - https://git.kernel.org/stable/c/20c0ed8dd65834e6bab464f54cd6ff68659bacb9 - https://git.kernel.org/stable/c/2d4060f05e74dbee884ba723f6afd9282befc3c5 - https://git.kernel.org/stable/c/db111468531777cac8b4beb6515a88a54b0c4a74 - https://git.kernel.org/stable/c/9dea08eac4f6d6fbbae59992978252e2edab995d - https://git.kernel.org/stable/c/6eadf50c1d894cb34f3237064063207460946040 - https://git.kernel.org/stable/c/64ec9a7e7a6398b172ab6feba60e952163a1c3d5 - https://git.kernel.org/stable/c/181698af38d3f93381229ad89c09b5bd0496661a
CVE ID: CVE-2025-38582 State: PUBLISHED Published: 2025-08-19T17:03:04.535Z Last Updated: 2025-09-29T05:54:13.704Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix double destruction of rsv_qp rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init(). list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]
try_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_
e] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18 References: - https://git.kernel.org/stable/c/dab173bae3303f074f063750a8dead2550d8c782 - https://git.kernel.org/stable/c/fc8b0f5b16bab2e032b4cfcd6218d5df3b80b2ea - https://git.kernel.org/stable/c/10b083dbba22be19baa848432b6f25aa68ab2db5 - https://git.kernel.org/stable/c/c6957b95ecc5b63c5a4bb4ecc28af326cf8f6dc8
CVE ID: CVE-2025-38583 State: PUBLISHED Published: 2025-08-19T17:03:05.340Z Last Updated: 2025-11-03T17:40:11.610Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: xilinx: vcu: unregister pll_post only if registered correctly If registration of pll_post is failed, it will be set to NULL or ERR, unregistering same will fail with following call trace: Unable to handle kernel NULL pointer dereference at virtual address 008 pc : clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_pr
00011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7e903da71f8bec4beb7c06707900e1ed8db843ca - https://git.kernel.org/stable/c/88bd875b7f9c3652c27d6e4bb7a23701b764f762 - https://git.kernel.org/stable/c/51990eecf22f446550befdfd1a9f54147eafd636 - https://git.kernel.org/stable/c/f1a1be99d5ae53d3b404415f1665eb59e8e02a8c - https://git.kernel.org/stable/c/86124c5cfceb5ac04d2fddbf1b6f7147332d96a3 - https://git.kernel.org/stable/c/a72b1c2d3b53e088bfaeb593949ff6fbd2cbe8ed - htt
6124c5cfceb5ac04d2fddbf1b6f7147332d96a3 - https://git.kernel.org/stable/c/a72b1c2d3b53e088bfaeb593949ff6fbd2cbe8ed - https://git.kernel.org/stable/c/3b0abc443ac22f7d4f61ddbbbbc5dbb06c87139d
CVE ID: CVE-2025-38584 State: PUBLISHED Published: 2025-08-19T17:03:06.172Z Last Updated: 2025-09-29T05:54:15.987Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: padata: Fix pd UAF once and for all There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as
ce is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives. References: - https://git.kernel.org/stable/c/dbe3e911a59bda6de96e7cae387ff882c2c177fa - https://git.kernel.org/stable/c/cdf79bd2e1ecb3cc75631c73d8f4149be6019a52 - https://git.kernel.org/stable/c/71203f68c7749609d7fc8ae6ad054bdedeb24f91
CVE ID: CVE-2025-38585 State: PUBLISHED Published: 2025-08-19T17:03:07.084Z Last Updated: 2025-09-29T05:54:17.156Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() When gmin_get_config_var() calls efi.get_variable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow: 1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure. 2. When efi.get_variable() returns EFI_
stale 'ret' value from earlier operations instead of indicating the EFI failure. 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded. The caller gmin_get_var_int() then performs: - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size - Due to bug #1, thinks call succeeded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer This creates a stack buffe
eded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution. Fix the bug by returning proper error codes from gmin_get_config_var() based on EFI status instead of stale 'ret' value. The gmin_get_var_int() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack. References: - https://git.kernel.org/stable/c/3d672fe065aa00f4d66f42e3c9720f69a3ed43e7 - ht
ng the atomisp camera stack. References: - https://git.kernel.org/stable/c/3d672fe065aa00f4d66f42e3c9720f69a3ed43e7 - https://git.kernel.org/stable/c/e6d3453a002e89537e6136f6c774659b297a549b - https://git.kernel.org/stable/c/1a7a2f59fb2eb0718a0cff1e5822500cefe50ed9 - https://git.kernel.org/stable/c/ee4cf798202d285dcbe85e4467a094c44f5ed8e6
CVE ID: CVE-2025-38586 State: PUBLISHED Published: 2025-08-19T17:03:08.012Z Last Updated: 2025-09-29T05:54:18.300Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix fp initialization for exception boundary In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF program, find_used_callee_regs() is not called because for a program acting as exception boundary, all callee saved registers are saved. find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP being used in any of the instructions. For programs acting as exception boundary, ctx->fp_used remains false even if frame pointer is used
of the instructions. For programs acting as exception boundary, ctx->fp_used remains false even if frame pointer is used by the program and therefore, FP is not set-up for such programs in the prologue. This can cause the kernel to crash due to a pagefault. Fix it by setting ctx->fp_used = true for exception boundary programs as fp is always saved in such programs. References: - https://git.kernel.org/stable/c/0dbef493cae7d451f740558665893c000adb2321 - https://git.kernel.org/stable/c/e23184725dbb72d5d02940222eee36dbba2aa422 - https://git.kernel.org/stable/c/1ce30231e0a2c8c361ee5f8f7f265fc17130adce - https://git.kernel.org/stable/c/b114fcee766d5101eada1aca7bb5fd0a86c89b35
CVE ID: CVE-2025-38587 State: PUBLISHED Published: 2025-08-19T17:03:08.924Z Last Updated: 2025-11-03T17:40:12.598Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in fib6_info_uses_dev() fib6_info_uses_dev() seems to rely on RCU without an explicit protection. Like the prior fix in rt6_nlmsg_size(), we need to make sure fib6_del_route() or fib6_add_rt2node() have not removed the anchor from the list, or we risk an infinite loop. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/bc85e62394f008fa848c4ba02c936c735a3e8ef5 - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/bc85e62394f008fa848c4ba02c936c735a3e8ef5 - https://git.kernel.org/stable/c/9cb6de8ee144a94ae7a40bdb32560329ab7276f0 - https://git.kernel.org/stable/c/db65739d406c72776fbdbbc334be827ef05880d2 - https://git.kernel.org/stable/c/16d21816c0918f8058b5fc14cbe8595d62046e2d - https://git.kernel.org/stable/c/e09be457b71b983a085312ff9e981f51e4ed3211 - https://git.kernel.org/stable/c/f8d8ce1b515a0a6af72b30502670a406cfb75073
CVE ID: CVE-2025-38588 State: PUBLISHED Published: 2025-08-19T17:03:09.856Z Last Updated: 2025-11-03T17:40:13.723Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent infinite loop in rt6_nlmsg_size() While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list. Restart the loop if f6i->fib
cu(), which can confuse rcu readers, because they might no longer see the head of the list. Restart the loop if f6i->fib6_nsiblings is zero. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6d345136c9b875f065d226908a29c25cdf9343f8 - https://git.kernel.org/stable/c/e1b7932af47f92432be8303d2439d1bf77b0be23 - https://git.kernel.org/stable/c/cd8d8bbd9ced4cc5d06d858f67d4aa87745e8f38 - https://git.kernel.org/stable/c/3c13db3e47e170bab19e574404e7b6be45ea873d - https://git.kernel.org/stable/c/46aeb66e9e54ed0d56c18615e1c3dbd502b327ab - https://git.kernel.org/stable/c/54e6fe9dd3b0e7c481c2228782c9494d653546da
CVE ID: CVE-2025-38589 State: PUBLISHED Published: 2025-08-19T17:03:10.791Z Last Updated: 2025-09-29T05:54:21.686Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: neighbour: Fix null-ptr-deref in neigh_flush_dev(). kernel test robot reported null-ptr-deref in neigh_flush_dev(). [0] The cited commit introduced per-netdev neighbour list and converted neigh_flush_dev() to use it instead of the global hash table. One thing we missed is that neigh_table_clear() calls neigh_ifdown() with NULL dev. Let's restore the hash table iteration. Note that IPv6 module is no longer unloadable, so neigh_table_clear() is called only when IPv6 fail
ash table iteration. Note that IPv6 module is no longer unloadable, so neigh_table_clear() is called only when IPv6 fails to initialise, which is unlikely to happen. [0]: IPv6: Attempt to unregister permanent protocol 136 IPv6: Attempt to unregister permanent protocol 17 Oops: general protection fault, probably for non-canonical address 0xdffffc00000001a0: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000d00-0x0000000000000d07] CPU: 1 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.12.0-rc6-01246-gf7f52738637f #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:neigh_flush_dev.llvm.6395807810224103582