Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
tially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0a9a182ea5c7bb0374e527130fd85024ace7279b - https://git.kernel.org/stable/c/24995851d58c4a205ad0ffa7b2f21e479a9c8527 - https://git.kernel.org/stable/c/ff825ab2f455299c0c7287550915a8878e2a66e0 - https://git.kernel.org/stable/c/aad6412c63baa39dd813e81f16a14d976b3de2e8 - https://git.kernel.org/stable/c/ce7356ae35943cc6494cc692e62d51a734062b7d
CVE ID: CVE-2024-53123 State: PUBLISHED Published: 2024-12-02T13:44:53.598Z Last Updated: 2025-11-03T22:29:30.464Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 f
0:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 <f7> 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:00000
88031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __
0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFL
4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected an
onnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a749b23059b43a9b1787eb36c5d9d44150a34238 - https://git.kernel.org/stable/c/a66805c9b22caf4e42af7a616f6c6b83c90d1010 - https://git.kernel.org/stable/c/955388e1d5d222c4101c596b536d41b91a8b212e - https://git.kernel.org/stable/c/581302298524e9d77c4c44ff5156a6cd112227ae
CVE ID: CVE-2024-53124 State: PUBLISHED Published: 2024-12-02T13:44:54.257Z Last Updated: 2025-11-03T20:46:04.223Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4
04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:00000000000000
04 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/
__sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_o
loc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +76
e() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/695fb0b9aecfd5dd5b2946ba8897ac2c1eef654d - https://git.kernel.org/stable/c/fe2c0bd6d1e29ccefdc978b9a290571c93c27473 - https://git.kern
dd5b2946ba8897ac2c1eef654d - https://git.kernel.org/stable/c/fe2c0bd6d1e29ccefdc978b9a290571c93c27473 - https://git.kernel.org/stable/c/c3d052cae566ec2285f5999958a5deb415a0f59e - https://git.kernel.org/stable/c/be7c61ea5f816168c38955eb4e898adc8b4b32fd - https://git.kernel.org/stable/c/3f51f8c9d28954cf380100883a02eed35a8277e9 - https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6 - https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cb
CVE ID: CVE-2024-53125 State: PUBLISHED Published: 2024-12-04T14:11:09.326Z Last Updated: 2025-11-03T20:46:07.020Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: sync_linked_regs() must preserve subreg_def Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto
+0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5). Additional A
2 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/dadf82c1b2608727bcc306843b540cd7414055a7 - https://git.kernel.org/stable/c/b57ac2d92c1f565743f6890a5b9cf317ed856b09 - https://git.kernel.org/stable/c/60fd3538d2a8fd44c41d25088c0ece3e1fd30659 - https://git.kernel.org/stable/c/bfe9446ea1d95f6cb7848da19dfd58d2eec6fd84 - https://git.kernel.org/stable/c/e2ef0f317a52e678fe8fa84b94d6a15b466d6ff0 - https://git.kernel.org/stable/c/e9bd9c498cb0f5843996dbe5cbce7a1836a83c70
CVE ID: CVE-2024-53126 State: PUBLISHED Published: 2024-12-04T14:20:30.788Z Last Updated: 2025-10-01T20:17:10.171Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). Additional Analyst Notes: - CIS
disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d372dd09cfbf1324f54cbffd81fcaf6cdf3e608e - https://git.kernel.org/stable/c/5bb287da2d2d5bb8f7376e223b02edb16998982e - https://git.kernel.org/stable/c/0b364cf53b20204e92bac7c6ebd1ee7d3ec62931
CVE ID: CVE-2024-53127 State: PUBLISHED Published: 2024-12-04T14:20:31.547Z Last Updated: 2025-11-03T22:29:31.953Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K" The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - "swiotlb buffer is full" and data corruption on StarFive JH7110 At this stage no fix have been found, so it
ive JH7100 - "swiotlb buffer is full" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/00bff71745bc3583bd5ca59be91e0ee1d27f1944 - https://git.kernel.org/stable/c/47693ba35bccaa16efa465159a1c12d78258349e - https://git.kernel.org/stable/c/938c13740f8b555986e53c0fcbaf00dcd1fabd4c - https://git.kernel.org/stable/c/f701eb601470bfc0a551913ce5f6ebaa770f0ce0 - https://git.kernel.org/stable/c/8f9416147d7ed414109d3501f1cb3d7a1735b25a - https://git.kernel.org/stable/c/
aa770f0ce0 - https://git.kernel.org/stable/c/8f9416147d7ed414109d3501f1cb3d7a1735b25a - https://git.kernel.org/stable/c/56de724c58c07a7ca3aac027cfd2ccb184ed9e4e - https://git.kernel.org/stable/c/a4685366f07448420badb710ff5c12aaaadf63ad - https://git.kernel.org/stable/c/1635e407a4a64d08a8517ac59ca14ad4fc785e75
CVE ID: CVE-2024-53128 State: PUBLISHED Published: 2024-12-04T14:20:34.985Z Last Updated: 2025-11-03T20:46:09.863Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082
subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c001
ff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 deb
18d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/82e813b12b10ff705f3f5d600d8492fc
l Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/82e813b12b10ff705f3f5d600d8492fc5248618b - https://git.kernel.org/stable/c/397383db9c69470642ac95beb04f2150928d663b - https://git.kernel.org/stable/c/2d2b19ed4169c38dc6c61a186c5f7bdafc709691 - https://git.kernel.org/stable/c/fbfe23012cec509dfbe09852019c4e4bb84999d0 - https://git.kernel.org/stable/c/fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58
CVE ID: CVE-2024-53129 State: PUBLISHED Published: 2024-12-04T14:20:35.907Z Last Updated: 2025-11-03T22:29:33.414Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4e47b99a7764b23a431bff6a3f91dfe77d294765 - https://git.kernel.org/stable/c/656dbd1c21c2c088c70059cdd43ec
el.org/stable/c/4e47b99a7764b23a431bff6a3f91dfe77d294765 - https://git.kernel.org/stable/c/656dbd1c21c2c088c70059cdd43ec83e7d54ec4d - https://git.kernel.org/stable/c/1e53059729691ca4d905118258b9fbd17d854174 - https://git.kernel.org/stable/c/bbf8bc7e75863942028131ae39c23118f62de6c0 - https://git.kernel.org/stable/c/ab1c793f457f740ab7108cc0b1340a402dbf484d
CVE ID: CVE-2024-53130 State: PUBLISHED Published: 2024-12-04T14:20:36.741Z Last Updated: 2025-11-03T22:29:34.891Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_gra
egardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called la
ay be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a - https://git.kernel.org/stable/c/0ce59fb1c73fdd5b6028226aeb46259a0cdc0957 - https://git.kernel.org/stable/c/0a5014ad37c77ac6a2c525137c00a0e1724f6020 - https://git.kernel.org/stable/c/d904e4d845aafbcfd8a40c1d
.kernel.org/stable/c/0a5014ad37c77ac6a2c525137c00a0e1724f6020 - https://git.kernel.org/stable/c/d904e4d845aafbcfd8a40c1df7d999f02f062be8 - https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95 - https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba - https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e9979944d1 - https://git.kernel.org/stable/c/2026559a6c4ce34db117d2db8f710fe2a9420d5a
CVE ID: CVE-2024-53131 State: PUBLISHED Published: 2024-12-04T14:20:37.455Z Last Updated: 2025-11-03T22:29:36.336Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabl
lled from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating
caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/085556bf8c70e2629e02e79268dac3016a08b8bf - https://git.kernel.org/stable/c/6438f3f42cda825f6f59b4e45ac3a1da28a6f2c9 - https://git.kernel.org/stable/c/b017697a517f8779ada4e8ce1c2c75dbf60a2636 - https://git.kernel.org/stable/c/19c71cdd77973f99a9adc3190130bc3aa7ae5423 - https://git.kernel.org/stable/c/3b2a4fd9bbee77afdd3ed5a05a0c02b6cde8d3b9 - https://git
7973f99a9adc3190130bc3aa7ae5423 - https://git.kernel.org/stable/c/3b2a4fd9bbee77afdd3ed5a05a0c02b6cde8d3b9 - https://git.kernel.org/stable/c/59b49ca67cca7b007a5afd3de0283c8008157665 - https://git.kernel.org/stable/c/77e47f89d32c2d72eb33d0becbce7abe14d061f4 - https://git.kernel.org/stable/c/cd45e963e44b0f10d90b9e6c0e8b4f47f3c92471
CVE ID: CVE-2024-53132 State: PUBLISHED Published: 2024-12-04T14:20:38.214Z Last Updated: 2025-10-01T20:17:10.037Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix "Missing outer runtime PM protection" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953