Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommufd_test+0xb19/0x16f0 Code: 94 c4 31 ff 44 89 e6 e8 a5 54 17 ff 45 84 e4 0f 85 bb 0b 00 00 41 be fb ff ff ff e8 31 53 17 ff e9 a0 f7 ff ff e8 27 53 17 ff <0f> 0b 41 be 8 RSP: 0018:ffffc90000eabdc0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8214c487 RDX: 0000000000000000 RSI: ffff88800f5c8000 RDI: 0000000000000002 RBP: ffffc90000eabe48 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: 00000000cd2b0000 R13: 00000000cd2af000 R14: 0000000000000000 R15: ffffc90000eabe68 FS: 00007f94d76d5740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0
0000000000000000 R15: ffffc90000eabe68 FS: 00007f94d76d5740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000043 CR3: 0000000006880006 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> ? write_comp_data+0x2f/0x90 iommufd_fops_ioctl+0x1ef/0x310 __x64_sys_ioctl+0x10e/0x160 ? __pfx_iommufd_fops_ioctl+0x10/0x10 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Check that the user memory range doesn't overflow. References: - https://git.kernel.org/stable/c/adac6508c235a092b91ed9c0110ecf140e9e9441 - https://git.kernel.org/stable/c/3fb3505636d033bbf7a0851dac63d01732c51d62 - https://git.kernel.org/stable/c/
140e9e9441 - https://git.kernel.org/stable/c/3fb3505636d033bbf7a0851dac63d01732c51d62 - https://git.kernel.org/stable/c/fd8c1a4aee973e87d890a5861e106625a33b2c4e
CVE ID: CVE-2023-53328 State: PUBLISHED Published: 2025-09-16T16:12:04.352Z Last Updated: 2025-09-17T11:02:55.849Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Enhance sanity check while generating attr_list ni_create_attr_list uses WARN_ON to catch error cases while generating attribute list, which only prints out stack trace and may not be enough. This repalces them with more proper error handling flow. [ 59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e [ 59.673268] #PF: supervisor read access in kernel mode [ 59.678354] #PF: error_code(0x0000) - not-present page [ 59.682831] PGD 80000000
supervisor read access in kernel mode [ 59.678354] #PF: error_code(0x0000) - not-present page [ 59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0 [ 59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI [ 59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G B W 6.2.0-rc1+ #4 [ 59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860 [ 59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8 [ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282 [ 59.735691] RAX: 00000000000000
4c 89 f7 e8 3f d0 d0 ff 4c 8d8 [ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282 [ 59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe [ 59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0 [ 59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9 [ 59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180 [ 59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050 [ 59.768323] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000 [ 59.776027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 0000
027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0 [ 59.787607] Call Trace: [ 59.790271] <TASK> [ 59.792488] ? __pfx_ni_create_attr_list+0x10/0x10 [ 59.797235] ? kernel_text_address+0xd3/0xe0 [ 59.800856] ? unwind_get_return_address+0x3e/0x60 [ 59.805101] ? __kasan_check_write+0x18/0x20 [ 59.809296] ? preempt_count_sub+0x1c/0xd0 [ 59.813421] ni_ins_attr_ext+0x52c/0x5c0 [ 59.817034] ? __pfx_ni_ins_attr_ext+0x10/0x10 [ 59.821926] ? __vfs_setxattr+0x121/0x170 [ 59.825718] ? __vfs_setxattr_noperm+0x97/0x300 [ 59.829562] ? __vfs_setxattr_locked+0x145/0x170 [ 59.833987] ? vfs_setxattr+0x137/0x2a0 [ 59.836732] ? do_se
0x97/0x300 [ 59.829562] ? __vfs_setxattr_locked+0x145/0x170 [ 59.833987] ? vfs_setxattr+0x137/0x2a0 [ 59.836732] ? do_setxattr+0xce/0x150 [ 59.839807] ? setxattr+0x126/0x140 [ 59.842353] ? path_setxattr+0x164/0x180 [ 59.845275] ? __x64_sys_setxattr+0x71/0x90 [ 59.848838] ? do_syscall_64+0x3f/0x90 [ 59.851898] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 59.857046] ? stack_depot_save+0x17/0x20 [ 59.860299] ni_insert_attr+0x1ba/0x420 [ 59.863104] ? __pfx_ni_insert_attr+0x10/0x10 [ 59.867069] ? preempt_count_sub+0x1c/0xd0 [ 59.869897] ? _raw_spin_unlock_irqrestore+0x2b/0x50 [ 59.874088] ? __create_object+0x3ae/0x5d0 [ 59.877865] ni_insert_resident+0xc4/0x1c0 [ 59.881430] ? __pfx_ni_insert_resid
59.874088] ? __create_object+0x3ae/0x5d0 [ 59.877865] ni_insert_resident+0xc4/0x1c0 [ 59.881430] ? __pfx_ni_insert_resident+0x10/0x10 [ 59.886355] ? kasan_save_alloc_info+0x1f/0x30 [ 59.891117] ? __kasan_kmalloc+0x8b/0xa0 [ 59.894383] ntfs_set_ea+0x90d/0xbf0 [ 59.897703] ? __pfx_ntfs_set_ea+0x10/0x10 [ 59.901011] ? kernel_text_address+0xd3/0xe0 [ 59.905308] ? __kernel_text_address+0x16/0x50 [ 59.909811] ? unwind_get_return_address+0x3e/0x60 [ 59.914898] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 59.920250] ? arch_stack_walk+0xa2/0x100 [ 59.924560] ? filter_irq_stacks+0x27/0x80 [ 59.928722] ntfs_setxattr+0x405/0x440 [ 59.932512] ? __pfx_ntfs_setxattr+0x10/0x10 [ 59.936634] ? kvmalloc_node+
7/0x80 [ 59.928722] ntfs_setxattr+0x405/0x440 [ 59.932512] ? __pfx_ntfs_setxattr+0x10/0x10 [ 59.936634] ? kvmalloc_node+0x2d/0x120 [ 59.940378] ? kasan_save_stack+0x41/0x60 [ 59.943870] ? kasan_save_stack+0x2a/0x60 [ 59.947719] ? kasan_set_track+0x29/0x40 [ 59.951417] ? kasan_save_alloc_info+0x1f/0x30 [ 59.955733] ? __kasan_kmalloc+0x8b/0xa0 [ 59.959598] ? __kmalloc_node+0x68/0x150 [ 59.963163] ? kvmalloc_node+0x2d/0x120 [ 59.966490] ? vmemdup_user+0x2b/0xa0 ---truncated--- References: - https://git.kernel.org/stable/c/e7799bb4dbe26bfb665f29ea87981708fd6012d8 - https://git.kernel.org/stable/c/4246bbef0442f4a1e974df0ab091f4f33ac69451 - https://git.kernel.org/stable/c/64fab8bce5237ca225ee1ec9d
kernel.org/stable/c/4246bbef0442f4a1e974df0ab091f4f33ac69451 - https://git.kernel.org/stable/c/64fab8bce5237ca225ee1ec9dff5cc8c31b0631f - https://git.kernel.org/stable/c/fdec309c7672cbee4dc0229ee4cbb33c948a1bdd
CVE ID: CVE-2023-53329 State: PUBLISHED Published: 2025-09-16T16:12:05.196Z Last Updated: 2025-09-16T16:12:05.196Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: workqueue: fix data race with the pwq->stats[] increment KCSAN has discovered a data race in kernel/workqueue.c:2598: [ 1863.554079] ================================================================== [ 1863.554118] BUG: KCSAN: data-race in process_one_work / process_one_work [ 1863.554142] write to 0xffff963d99d79998 of 8 bytes by task 5394 on cpu 27: [ 1863.554154] process_one_work (kernel/workqueue.c:2598) [ 1863.554166] worker_thread (./include/linux/list.h:292 kern
[ 1863.554154] process_one_work (kernel/workqueue.c:2598) [ 1863.554166] worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2752) [ 1863.554177] kthread (kernel/kthread.c:389) [ 1863.554186] ret_from_fork (arch/x86/kernel/process.c:145) [ 1863.554197] ret_from_fork_asm (arch/x86/entry/entry_64.S:312) [ 1863.554213] read to 0xffff963d99d79998 of 8 bytes by task 5450 on cpu 12: [ 1863.554224] process_one_work (kernel/workqueue.c:2598) [ 1863.554235] worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2752) [ 1863.554247] kthread (kernel/kthread.c:389) [ 1863.554255] ret_from_fork (arch/x86/kernel/process.c:145) [ 1863.554266] ret_from_fork_asm (arch/x86/entry/entry_64.S:312
63.554255] ret_from_fork (arch/x86/kernel/process.c:145) [ 1863.554266] ret_from_fork_asm (arch/x86/entry/entry_64.S:312) [ 1863.554280] value changed: 0x0000000000001766 -> 0x000000000000176a [ 1863.554295] Reported by Kernel Concurrency Sanitizer on: [ 1863.554303] CPU: 12 PID: 5450 Comm: kworker/u64:1 Tainted: G L 6.5.0-rc6+ #44 [ 1863.554314] Hardware name: ASRock X670E PG Lightning/X670E PG Lightning, BIOS 1.21 04/26/2023 [ 1863.554322] Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] [ 1863.554941] ================================================================== lockdep_invariant_state(true); → pwq->stats[PWQ_STAT_STARTED]++; trace_workqueue_execute_start(work); worker->current_func
ckdep_invariant_state(true); → pwq->stats[PWQ_STAT_STARTED]++; trace_workqueue_execute_start(work); worker->current_func(work); Moving pwq->stats[PWQ_STAT_STARTED]++; before the line raw_spin_unlock_irq(&pool->lock); resolves the data race without performance penalty. KCSAN detected at least one additional data race: [ 157.834751] ================================================================== [ 157.834770] BUG: KCSAN: data-race in process_one_work / process_one_work [ 157.834793] write to 0xffff9934453f77a0 of 8 bytes by task 468 on cpu 29: [ 157.834804] process_one_work (/home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2606) [ 157.834815] worker_thread (/home/marvin/linux/ker
k (/home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2606) [ 157.834815] worker_thread (/home/marvin/linux/kernel/linux_torvalds/./include/linux/list.h:292 /home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2752) [ 157.834826] kthread (/home/marvin/linux/kernel/linux_torvalds/kernel/kthread.c:389) [ 157.834834] ret_from_fork (/home/marvin/linux/kernel/linux_torvalds/arch/x86/kernel/process.c:145) [ 157.834845] ret_from_fork_asm (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/entry_64.S:312) [ 157.834859] read to 0xffff9934453f77a0 of 8 bytes by task 214 on cpu 7: [ 157.834868] process_one_work (/home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2606) [ 15
ask 214 on cpu 7: [ 157.834868] process_one_work (/home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2606) [ 157.834879] worker_thread (/home/marvin/linux/kernel/linux_torvalds/./include/linux/list.h:292 /home/marvin/linux/kernel/linux_torvalds/kernel/workqueue.c:2752) [ 157.834890] kthread (/home/marvin/linux/kernel/linux_torvalds/kernel/kthread.c:389) [ 157.834897] ret_from_fork (/home/marvin/linux/kernel/linux_torvalds/arch/x86/kernel/process.c:145) [ 157.834907] ret_from_fork_asm (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/entry_64.S:312) [ 157.834920] value changed: 0x000000000000052a -> 0x0000000000000532 [ 157.834933] Reported by Kernel Concurrency Sanitizer on:
920] value changed: 0x000000000000052a -> 0x0000000000000532 [ 157.834933] Reported by Kernel Concurrency Sanitizer on: [ 157.834941] CPU: 7 PID: 214 Comm: kworker/u64:2 Tainted: G L 6.5.0-rc7-kcsan-00169-g81eaf55a60fc #4 [ 157.834951] Hardware name: ASRock X670E PG Lightning/X670E PG Lightning, BIOS 1.21 04/26/2023 [ 157.834958] Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] [ 157.835567] ================================================================== in code: trace_workqueue_execute_end(work, worker->current_func); → pwq->stats[PWQ_STAT_COM ---truncated--- References: - https://git.kernel.org/stable/c/ce55024f28589b0012fa2c6b5748ec5a180b7fbe - https://git.kernel.org/stable/c/fe48ba7d
s: - https://git.kernel.org/stable/c/ce55024f28589b0012fa2c6b5748ec5a180b7fbe - https://git.kernel.org/stable/c/fe48ba7daefe75bbbefa2426deddc05f2d530d2d
CVE ID: CVE-2023-53330 State: PUBLISHED Published: 2025-09-16T16:12:06.005Z Last Updated: 2025-09-16T16:12:06.005Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: caif: fix memory leak in cfctrl_linkup_request() When linktype is unknown or kzalloc failed in cfctrl_linkup_request(), pkt is not released. Add release process to error path. References: - https://git.kernel.org/stable/c/badea57569db04b010e922e29a7aaf40a979a70b - https://git.kernel.org/stable/c/3acf3783a84cbdf0c9f8cf2f32ee9c49af93a2da - https://git.kernel.org/stable/c/33df9c5d5e2a18c70f5f5f3c2757d654c1b6ffa3 - https://git.kernel.org/stable/c/84b2cc7b36b7f6957d307fb3d0
ernel.org/stable/c/33df9c5d5e2a18c70f5f5f3c2757d654c1b6ffa3 - https://git.kernel.org/stable/c/84b2cc7b36b7f6957d307fb3d01603f93cb2d655 - https://git.kernel.org/stable/c/dc1bc903970bdf63ca40ab923d3ccb765da9a8d9 - https://git.kernel.org/stable/c/1dddeceb26002cfea4c375e92ac6498768dc7349 - https://git.kernel.org/stable/c/3ad47c8aa5648226184415e4a0cb1bf67ffbfd48 - https://git.kernel.org/stable/c/fe69230f05897b3de758427b574fc98025dfc907
CVE ID: CVE-2023-53331 State: PUBLISHED Published: 2025-09-16T16:12:06.788Z Last Updated: 2025-09-16T16:12:06.788Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Check start of empty przs during init After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as valid"), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c
e access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ... To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start > size) and zap the buffer back to a sane state. [kees: update commit log with backtrac
eck case will discover it (start > size) and zap the buffer back to a sane state. [kees: update commit log with backtrace and clarifications] References: - https://git.kernel.org/stable/c/89312657337e6e03ad6e9ea1a462bd9c158c85c8 - https://git.kernel.org/stable/c/c807ccdd812d18985860504b503899f3140a9549 - https://git.kernel.org/stable/c/e972231db29b5d1dccc13bf9d5ba55b6979a69ed - https://git.kernel.org/stable/c/dc2f60de9a7d3efd982440117dab5579898d808c - https://git.kernel.org/stable/c/fedecaeef88899d940b69368c996e8b3b0b8650d - https://git.kernel.org/stable/c/e95d7a8a6edd14f8fab44c777dd7281db91f6ae2 - https://git.kernel.org/stable/c/f77990358628b01bdc03752126ff5f716ea37615 - https://git.kernel.
ab44c777dd7281db91f6ae2 - https://git.kernel.org/stable/c/f77990358628b01bdc03752126ff5f716ea37615 - https://git.kernel.org/stable/c/25fb4e3402d46f425ec135ef6f09792a4c1b3003 - https://git.kernel.org/stable/c/fe8c3623ab06603eb760444a032d426542212021
CVE ID: CVE-2023-53332 State: PUBLISHED Published: 2025-09-16T16:12:07.573Z Last Updated: 2025-09-16T16:12:07.573Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask() If ipi_send_{mask|single}() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Add a missing NULL pointer check in ipi_send_verify()... Found by Linux Verification Center (li
inter gets dereferenced. Add a missing NULL pointer check in ipi_send_verify()... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. References: - https://git.kernel.org/stable/c/926aef60ea64cd9becf2829f7388f48dbe8bcb11 - https://git.kernel.org/stable/c/7448c73d64075051f50caed2c62f46553b69ab8a - https://git.kernel.org/stable/c/feabecaff5902f896531dde90646ca5dfa9d4f7d
CVE ID: CVE-2023-53333 State: PUBLISHED Published: 2025-09-16T16:12:08.427Z Last Updated: 2025-09-16T16:12:08.427Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one Eric Dumazet says: nf_conntrack_dccp_packet() has an unique: dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); And nothing more is 'pulled' from the packet, depending on the content. dh->dccph_doff, and/or dh->dccph_x ...) So dccp_ack_seq() is happily reading stuff past the _dh buffer. BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0 Read of size 4 at add
uff past the _dh buffer. BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0 Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371 [..] Fix this by increasing the stack buffer to also include room for the extra sequence numbers and all the known dccp packet type headers, then pull again after the initial validation of the basic header. While at it, mark packets invalid that lack 48bit sequence bit but where RFC says the type MUST use them. Compile tested only. v2: first skb_header_pointer() now needs to adjust the size to only pull the generic header. (Eric) Heads-up: I intend to remove dccp conntrack support later this year. References: - https://git.ker
eneric header. (Eric) Heads-up: I intend to remove dccp conntrack support later this year. References: - https://git.kernel.org/stable/c/337fdce450637ea663bc816edc2ba81e5cdad02e - https://git.kernel.org/stable/c/9bdcda7abaf22f6453e5b5efb7eb4e524095d5d8 - https://git.kernel.org/stable/c/c052797ac36813419ad3bfa54cb8615db4b41f15 - https://git.kernel.org/stable/c/5c618daa5038712c4a4ef8923905a2ea1b8836a1 - https://git.kernel.org/stable/c/26bd1f210d3783a691052c51d76bb8a8bbd24c67 - https://git.kernel.org/stable/c/8c0980493beed3a80d6329c44ab293dc8c032927 - https://git.kernel.org/stable/c/ff0a3a7d52ff7282dbd183e7fc29a1fe386b0c30
CVE ID: CVE-2023-53334 State: PUBLISHED Published: 2025-09-16T16:12:09.226Z Last Updated: 2025-09-16T16:12:09.226Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: USB: chipidea: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. References: - https://git.kernel.org/stable/c/4322661af6d7a586a5798ab9aa443f49895b6943 - https://git.kernel.org/stable/c/610373dd354f3d393aa3bdcab59f55024c16b5e5 - https://git.kernel.org/sta
aa443f49895b6943 - https://git.kernel.org/stable/c/610373dd354f3d393aa3bdcab59f55024c16b5e5 - https://git.kernel.org/stable/c/972e0682f6e3ee6ecf002657df4aaa511d51dd6c - https://git.kernel.org/stable/c/ff35f3ea3baba5b81416ac02d005cfbf6dd182fa
CVE ID: CVE-2023-53335 State: PUBLISHED Published: 2025-09-17T14:56:29.672Z Last Updated: 2025-09-17T14:56:29.672Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish() If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is dereferenced later regardless of whether it is empty. This patch adds a simple sanity check to fix the issue. Found by Linux Verification Center (linuxtesting.org) with SVACE. References: - https://git.kernel.org/stable/c/9dca64042d855a24b0bd81ce242e5dc7e939f6eb - https://git.kernel.org/stable/c/2cfc00e974d75a3aa8155f2660f57d342e1f67ca - https:
64042d855a24b0bd81ce242e5dc7e939f6eb - https://git.kernel.org/stable/c/2cfc00e974d75a3aa8155f2660f57d342e1f67ca - https://git.kernel.org/stable/c/9ddc77eefb2a567b705c3c86ab2ddabe43cadf1b - https://git.kernel.org/stable/c/283861a4c52c1ea4df3dd1b6fc75a50796ce3524
CVE ID: CVE-2023-53336 State: PUBLISHED Published: 2025-09-17T14:56:30.752Z Last Updated: 2025-09-17T14:56:30.752Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run sensor->adev is not set yet. So if either of the dev_warn() calls about unknown values are hit this will lead to a NULL pointer deref. Set sensor->adev earlier, with a borrowed ref to avoid making unrolling on errors harder, to fix this. References: - https://git.kernel.org/stable/c/3de35e29cfddfe6bff762b15bcfe8d80bebac6cb - htt
errors harder, to fix this. References: - https://git.kernel.org/stable/c/3de35e29cfddfe6bff762b15bcfe8d80bebac6cb - https://git.kernel.org/stable/c/e08b091e33ecf6e4cb2c0c5820a69abe7673280b - https://git.kernel.org/stable/c/284be5693163343e1cf17c03917eecd1d6681bcf
CVE ID: CVE-2023-53337 State: PUBLISHED Published: 2025-09-17T14:56:31.582Z Last Updated: 2025-09-17T14:56:31.582Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not write dirty data after degenerating to read-only According to syzbot's report, mark_buffer_dirty() called from nilfs_segctor_do_construct() outputs a warning with some patterns after nilfs2 detects metadata corruption and degrades to read-only mode. After such read-only degeneration, page cache data may be cleared through nilfs_clear_dirty_page() which may also clear the uptodate flag for their buffer heads. However, even after the degeneration, log writ
rty_page() which may also clear the uptodate flag for their buffer heads. However, even after the degeneration, log writes are still performed by unmount processing etc., which causes mark_buffer_dirty() to be called for buffer heads without the "uptodate" flag and causes the warning. Since any writes should not be done to a read-only file system in the first place, this fixes the warning in mark_buffer_dirty() by letting nilfs_segctor_do_construct() abort early if in read-only mode. This also changes the retry check of nilfs_segctor_write_out() to avoid unnecessary log write retries if it detects -EROFS that nilfs_segctor_do_construct() returned. References: - https://git.kernel.org/stable/
te retries if it detects -EROFS that nilfs_segctor_do_construct() returned. References: - https://git.kernel.org/stable/c/bd89073fc7a5d03b1d06b372addbe405e5a925f4 - https://git.kernel.org/stable/c/e9c5412c5972124776c1b873533eb39e287a4dfa - https://git.kernel.org/stable/c/4569a292a84e340e97d178898ad1cfe1a3080a61 - https://git.kernel.org/stable/c/7c3e662048053802f6b0db3a78e97f4e1f7edc4f - https://git.kernel.org/stable/c/13f73ef77baa4764dc1ca4fcbae9cade05b83866 - https://git.kernel.org/stable/c/a73201c607d8e506358d60aafddda4246bdd9350 - https://git.kernel.org/stable/c/4005cec6847c06ee191583270b7cdd7e696543cc - https://git.kernel.org/stable/c/55f7810632f993cff622a0ddbc7c865892294b61 - https://gi
847c06ee191583270b7cdd7e696543cc - https://git.kernel.org/stable/c/55f7810632f993cff622a0ddbc7c865892294b61 - https://git.kernel.org/stable/c/28a65b49eb53e172d23567005465019658bfdb4d
CVE ID: CVE-2023-53338 State: PUBLISHED Published: 2025-09-17T14:56:32.302Z Last Updated: 2025-09-17T14:56:32.302Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lwt: Fix return values of BPF xmit ops BPF encap ops can return different types of positive values, such like NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in ip(6)_finish_output2. When this happens, skbs that have been freed would continue to the neighbor subsystem, causing use-after-free bug and kernel crashes. To f