Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_wo
ut+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7
on.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 </TASK> Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]--- Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e0d9a7cf37ca09c513420dc88e0d0e805a4f0820 - https://git.kernel.org/stable/c/8c8e8
nces: - https://git.kernel.org/stable/c/e0d9a7cf37ca09c513420dc88e0d0e805a4f0820 - https://git.kernel.org/stable/c/8c8e8d4d7544bb783e15078eda8ba2580e192246 - https://git.kernel.org/stable/c/fd044c99d831e9f837518816c7c366b04014d405 - https://git.kernel.org/stable/c/b5725213149597cd9c2b075b87bc4e0f87e906c1 - https://git.kernel.org/stable/c/ecf371f8b02d5e31b9aa1da7f159f1b2107bdb01
CVE ID: CVE-2025-38456 State: PUBLISHED Published: 2025-07-25T15:27:35.559Z Last Updated: 2025-11-03T17:38:12.328Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipmi:msghandler: Fix potential memory corruption in ipmi_create_user() The "intf" list iterator is an invalid pointer if the correct "intf->intf_num" is not found. Calling atomic_dec(&intf->nr_users) on and invalid pointer will lead to memory corruption. We don't really need to call atomic_dec() if we haven't called atomic_add_return() so update the if (intf->in_shutdown) path as well. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.
f (intf->in_shutdown) path as well. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/cbc1670297f675854e982d23c8583900ff0cc67a - https://git.kernel.org/stable/c/e2d5c005dfc96fe857676d1d8ac46b29275cb89b - https://git.kernel.org/stable/c/9e0d33e75c1604c3fad5586ad4dfa3b2695a3950 - https://git.kernel.org/stable/c/7c1a6ddb99858e7d68961f74ae27caeeeca67b6a - https://git.kernel.org/stable/c/fa332f5dc6fc662ad7d3200048772c96b861cf6b
CVE ID: CVE-2025-38457 State: PUBLISHED Published: 2025-07-25T15:27:36.226Z Last Updated: 2025-11-03T17:38:14.193Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sched: Abort __tc_modify_qdisc if parent class does not exist Lion's patch [1] revealed an ancient bug in the qdisc API. Whenever a user creates/modifies a qdisc specifying as a parent another qdisc, the qdisc API will, during grafting, detect that the user is not trying to attach to a class and reject. However grafting is performed after qdisc_create (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during i
eate (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during init or change (such as fq, hhf, choke, etc), an issue arises. For example, executing the following commands: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Qdiscs such as fq, hhf, choke, etc unconditionally invoke qdisc_tree_reduce_backlog() in their control path init() or change() which then causes a failure to find the child class; however, that does not stop the unconditional invocation of the assumed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null. The solut
umed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null. The solution is ensure that qdisc_leaf() which looks up the parent class, and is invoked prior to qdisc_create(), should return failure on not finding the class. In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the parentid doesn't correspond to a class, so that we can detect it earlier on and abort before qdisc_create is called. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/ Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/923a276c74e25073ae391e930792ac86a9f77f1e - https://git.kerne
am Container: References: - https://git.kernel.org/stable/c/923a276c74e25073ae391e930792ac86a9f77f1e - https://git.kernel.org/stable/c/90436e72c9622c2f70389070088325a3232d339f - https://git.kernel.org/stable/c/25452638f133ac19d75af3f928327d8016952c8e - https://git.kernel.org/stable/c/23c165dde88eac405eebb59051ea1fe139a45803 - https://git.kernel.org/stable/c/4c691d1b6b6dbd73f30ed9ee7da05f037b0c49af - https://git.kernel.org/stable/c/8ecd651ef24ab50123692a4e3e25db93cb11602a - https://git.kernel.org/stable/c/e28a383d6485c3bb51dc5953552f76c4dea33eea - https://git.kernel.org/stable/c/ffdde7bf5a439aaa1955ebd581f5c64ab1533963
CVE ID: CVE-2025-38458 State: PUBLISHED Published: 2025-07-25T15:27:37.164Z Last Updated: 2025-11-03T17:38:16.061Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix NULL pointer dereference in vcc_sendmsg() atmarpd_dev_ops does not implement the send method, which may cause crash as bellow. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:
EMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246 RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000 RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000 RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287 R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00 R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88 FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffff
00) GS:ffff88808d6c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x
t.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9ec7e943aee5c28c173933f9defd40892fb3be3d - https://git.kernel.org/stable/c/a16fbe6087e91c8e7c4aa50e1af7ad56edbd9e3e - https://git.kernel.org/stable/c/7f1cad84ac1a6af42d9d57e879de47ce37995024 - https://git.kernel.org/stable/c/27b5bb7ea1a8fa7b8c4cfde4d2bf8650cca2e8e8 - https://git.kernel.org/stable/c/07b58
95024 - https://git.kernel.org/stable/c/27b5bb7ea1a8fa7b8c4cfde4d2bf8650cca2e8e8 - https://git.kernel.org/stable/c/07b585ae3699c0a5026f86ac846f144e34875eee - https://git.kernel.org/stable/c/34a09d6240a25185ef6fc5a19dbb3cdbb6a78bc0 - https://git.kernel.org/stable/c/7f8a9b396037daae453a108faec5b28886361323 - https://git.kernel.org/stable/c/22fc46cea91df3dce140a7dc6847c6fcf0354505
CVE ID: CVE-2025-38459 State: PUBLISHED Published: 2025-07-25T15:27:37.893Z Last Updated: 2025-11-03T17:38:17.937Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix infinite recursive call of clip_push(). syzbot reported the splat below. [0] This happens if we call ioctl(ATMARP_MKIP) more than once. During the first call, clip_mkip() sets clip_push() to vcc->push(), and the second call copies it to clip_vcc->old_push(). Later, when the socket is close()d, vcc_destroy_socket() passes NULL skb to clip_push(), which calls clip_vcc->old_push(), triggering the infinite recursion. Let's prevent the second ioctl(ATMARP_MKI
p_push(), which calls clip_vcc->old_push(), triggering the infinite recursion. Let's prevent the second ioctl(ATMARP_MKIP) by checking vcc->user_back, which is allocated by the first call as clip_vcc. Note also that we use lock_sock() to prevent racy calls. [0]: BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000) Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f
2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knl
3: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace: <TASK> clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 ... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 _
ease+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 Code: ff ff c3 66 2e 0f 1f 84 00
try/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 </TASK> Modu
1: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 </TASK> Modules linked in: Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f493f31a63847624fd3199ac836a8bd8828e50e2 - https://git.kernel.org/stable/c/125166347d5676466d368aadc0bbc31ee7714352 - https://git.kernel.org/stable/c/5641019dfbaee5e85fe093b590f0451c9dd4d6f8 - https://git.kernel.org/stable/c/1579a2777cb914a249de22c789ba4d41b154509f - https://git.kernel.org/stable/c/3f61b997fe014bbfcc208a9fcbd363a1fe7e3a31 - https://git.kernel.org/stable/c/024876b247a882972095b22087734dcd23396a4e - https://git.kernel.org/stable/c/df0312d8859763aa15
://git.kernel.org/stable/c/024876b247a882972095b22087734dcd23396a4e - https://git.kernel.org/stable/c/df0312d8859763aa15b8b56ac151a1ea4a4e5b88 - https://git.kernel.org/stable/c/c489f3283dbfc0f3c00c312149cae90d27552c45
CVE ID: CVE-2025-38460 State: PUBLISHED Published: 2025-07-25T15:27:38.608Z Last Updated: 2025-11-03T17:38:19.880Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix potential null-ptr-deref in to_atmarpd(). atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip causes unregister hang"). However, it is not enough because to_atmarpd() is called without RTNL, especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable. Also, there is no RTNL dependency around atmarpd. Let's use a private mutex and RCU to protect access to atmarpd in to_atmarpd(). Additional Analyst Notes: - CVE Program Container
a private mutex and RCU to protect access to atmarpd in to_atmarpd(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a4c5785feb979cd996a99cfaad8bf353b2e79301 - https://git.kernel.org/stable/c/70eac9ba7ce25d99c1d99bbf4ddb058940f631f9 - https://git.kernel.org/stable/c/3251ce3979f41bd228f77a7615f9dd616d06a110 - https://git.kernel.org/stable/c/ee4d9e4ddf3f9c4ee2ec0a3aad6196ee36d30e57 - https://git.kernel.org/stable/c/06935c50cfa3ac57cce80bba67b6d38ec1406e92 - https://git.kernel.org/stable/c/36caab990b69ef4eec1d81c52a19f080b7daa059 - https://git.kernel.org/stable/c/f58e4270c73e7f086322978d585ea67c8076ce49 - https://git.kernel.org/stable/c/706cc36
059 - https://git.kernel.org/stable/c/f58e4270c73e7f086322978d585ea67c8076ce49 - https://git.kernel.org/stable/c/706cc36477139c1616a9b2b96610a8bb520b7119
CVE ID: CVE-2025-38461 State: PUBLISHED Published: 2025-07-25T15:27:39.322Z Last Updated: 2025-11-03T17:38:21.774Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_* TOCTOU Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer. This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+
rt+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8667e8d0eb46bc54fdae30ba2f4786407d3d88eb - https://git.kernel.org/stable/c/36a439049b34cca0b3661276049b84a1f76cc21a - https://git.kernel.org/stable/c/9ce53e744f18e73059d3124070e960f3aa9902bf - https://git.kernel.org/stable/c/9d24bb6780282b0255b9929abe5e8f98007e2c6e - https://git.kernel.org/stable/c/ae2c712ba39c7007de63cb0c75b51ce1caaf1da5 - https://git.kernel.org/stable/c/7b73bddf54777fb62d4d8c7729d0affe6df04477 - https://git.k
c7007de63cb0c75b51ce1caaf1da5 - https://git.kernel.org/stable/c/7b73bddf54777fb62d4d8c7729d0affe6df04477 - https://git.kernel.org/stable/c/687aa0c5581b8d4aa87fd92973e4ee576b550cdf
CVE ID: CVE-2025-38462 State: PUBLISHED Published: 2025-07-25T15:27:45.168Z Last Updated: 2025-11-03T17:38:23.677Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_{g2h,h2g} TOCTOU vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload. transport_{g2h,h2g} may become NULL after the NULL check. Introduce vsock_transport_local_cid() to protect from a potential null-ptr-deref. KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_find_cid+0x47/0x90 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_6
0 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0 Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c5496ee685c48ed1cc183cd4263602579bb4a615 - https://git.kernel.org/stable/c/80d7dc15805a93d520a249ac6d13d4f4df161c1b - https://git.kernel.org/stable/c/5752d8dbb3dfd7f1a9faf0f65377e60826ea9a17 - https://git.k
a93d520a249ac6d13d4f4df161c1b - https://git.kernel.org/stable/c/5752d8dbb3dfd7f1a9faf0f65377e60826ea9a17 - https://git.kernel.org/stable/c/401239811fa728fcdd53e360a91f157ffd23e1f4 - https://git.kernel.org/stable/c/3734d78210cceb2ee5615719a62a5c55ed381ff8 - https://git.kernel.org/stable/c/6a1bcab67bea797d83aa9dd948a0ac6ed52d121d - https://git.kernel.org/stable/c/209fd720838aaf1420416494c5505096478156b4
CVE ID: CVE-2025-38463 State: PUBLISHED Published: 2025-07-25T15:27:45.975Z Last Updated: 2025-07-28T04:23:11.023Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len:
kb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction will result in copy holding a very large positive integer. In the subsequent logic, this large value is used to update sk->s
result in copy holding a very large positive integer. In the subsequent logic, this large value is used to update sk->sk_forward_alloc, which can easily cause it to overflow. The syzkaller reproducer uses TCP_REPAIR to reliably create this condition. However, this can also occur in real-world scenarios. The tcp_bound_to_half_wnd() function can also reduce size_goal to a small value. This would cause the subsequent tcp_wmem_schedule() to set sk->sk_forward_alloc to a value close to INT_MAX. Further memory allocation requests would then cause sk_forward_alloc to wrap around and become negative. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47 References: - https://git.kernel.
and become negative. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47 References: - https://git.kernel.org/stable/c/81373cd1d72d87c7d844d4454a526b8f53e72d00 - https://git.kernel.org/stable/c/62e6160cfb5514787bda833d466509edc38fde23 - https://git.kernel.org/stable/c/9f164fa6bb09fbcc60fa5c3ff551ce9eec1befd7 - https://git.kernel.org/stable/c/d3a5f2871adc0c61c61869f37f3e697d97f03d8c
CVE ID: CVE-2025-38464 State: PUBLISHED Published: 2025-07-25T15:27:46.708Z Last Updated: 2025-11-03T17:38:25.539Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_conn_close(). syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0] tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn. The problem is that tipc_conn_close() is called after releasing the IDR lock. At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref. Once we
conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref. Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive. Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop(). [0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435 CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stac
Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kerne