Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ges.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0 </IRQ> Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4b9a086eedc1fddae632310386098c12155e3d0a - https:
- CVE Program Container: References: - https://git.kernel.org/stable/c/4b9a086eedc1fddae632310386098c12155e3d0a - https://git.kernel.org/stable/c/ad17eb86d042d72a59fd184ad1adf34f5eb36843 - https://git.kernel.org/stable/c/f26fe7c3002516dd3c288f1012786df31f4d89e0 - https://git.kernel.org/stable/c/8ebcd311b4866ab911d1445ead08690e67f0c488 - https://git.kernel.org/stable/c/69541e58323ec3e3904e1fa87a6213961b1f52f4 - https://git.kernel.org/stable/c/3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7 - https://git.kernel.org/stable/c/0bdc924bfb319fb10d1113cbf091fc26fb7b1f99
CVE ID: CVE-2025-38147 State: PUBLISHED Published: 2025-07-03T08:35:52.921Z Last Updated: 2025-11-03T17:34:39.593Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: calipso: Don't call calipso functions for AF_INET sk. syzkaller reported a null-ptr-deref in txopt_get(). [0] The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo, so struct ipv6_pinfo was NULL there. However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6 is always set in inet6_create(), meaning the socket was not IPv6 one. The root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct so
he root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct sockaddr.sa_family, which is passed from userspace. However, netlbl_conn_setattr() does not check if the address family matches the socket. The syzkaller must have called connect() for an IPv6 address on an IPv4 socket. We have a proper validation in tcp_v[46]_connect(), but security_socket_connect() is called in the earlier stage. Let's copy the validation to netlbl_conn_setattr(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
fffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:txopt_get include/net/ipv6.h:390 [inline] RIP: 0010: Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00 RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000
ffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070 RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00 R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80 FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: <TASK> calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socke
t/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x
[inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f901b61a12d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 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:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003 RBP: 00007f901b701505 R08: 00
a0 RCX: 00007f901b61a12d RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003 RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 </TASK> Modules linked in: Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fc2da88411470480b8b7e9177e930cedd893cf56 - https://git.kernel.org/stable/c/0c813dbc851dbf418fdc6dc883fd0592d6c555cd - https://git.kernel.org/stable/c/26ce90f1ce60b0ff587de8d6aec399aa55cab28e - https://git.kernel.org/stable/c/c32ebe33626335a536dbbdd09571c06dd9bc1729 - https://git.kernel.
87de8d6aec399aa55cab28e - https://git.kernel.org/stable/c/c32ebe33626335a536dbbdd09571c06dd9bc1729 - https://git.kernel.org/stable/c/946bfdfcb76ac2bac5b8526447035885ff41c598 - https://git.kernel.org/stable/c/dd8928897594931d6912ef2f7a43e110b4958d3d - https://git.kernel.org/stable/c/e2ec310c7a50271843c585e27ef14e48c66ce649 - https://git.kernel.org/stable/c/6e9f2df1c550ead7cecb3e450af1105735020c92
CVE ID: CVE-2025-38148 State: PUBLISHED Published: 2025-07-03T08:35:53.544Z Last Updated: 2025-11-03T17:34:40.556Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: phy: mscc: Fix memory leak when using one step timestamping Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping. Additional Ana
mped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/24b24295464f25fb771d36ed558c7cd942119361 - https://git.kernel.org/stable/c/db2a12ddd3a31f668137ff6a4befc1343c79cbc4 - https://git.kernel.org/stable/c/0b40aeaf83ca04d4c9801e235b7533400c8b5f17 - https://git.kernel.org/stable/c/66abe22017522dd56b820e41ca3a5b131a637001 - https://git.kernel.org/stable/c/cdbabd316c5a4a9b0fda6aafe491e2db17fbb95d - https://git.kernel.org/stable/c/846992645b25ec4253167e3f931e4597eb84af56
CVE ID: CVE-2025-38149 State: PUBLISHED Published: 2025-07-03T08:35:54.405Z Last Updated: 2025-07-28T04:13:37.893Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: phy: clear phydev->devlink when the link is deleted There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_de
but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is delete
4.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted. References: - https://git.kernel.org/stable/c/363fdf2777423ad346d781f09548cca14877f729 - https://git.kernel.org/stable/c/ddc654e89ace723b78c34911c65243accbc9b75c - https://git.kernel.org/stable/c/034bc4a2a72dea2cfcaf24c6bae03c38ad5a0b87 - https://git.kernel.org/stable/c/0795b05a59b1371b18ffbf09d385296b12e9f5d5
CVE ID: CVE-2025-38150 State: PUBLISHED Published: 2025-07-03T08:35:55.257Z Last Updated: 2025-07-28T04:13:39.528Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: af_packet: move notifier's packet_dev_mc out of rcu critical section Syzkaller reports the following issue: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 __mutex_lock+0x106/0xe80 kernel/locking/mutex.c:746 team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781 dev_change_rx_flags net/core/dev.c:9145 [inline] __dev_set_promiscuity+0x3f8/0x590 net/core/dev.c:9189 netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9201 dev_set_pro
e] __dev_set_promiscuity+0x3f8/0x590 net/core/dev.c:9189 netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9201 dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:286 packet_dev_mc net/packet/af_packet.c:3698 [inline] packet_dev_mclist_delete net/packet/af_packet.c:3722 [inline] packet_notifier+0x292/0xa60 net/packet/af_packet.c:4247 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2214 [inline] call_netdevice_notifiers net/core/dev.c:2228 [inline] unregister_netdevice_many_notify+0x15d8/0x2330 net/core/dev.c:11972 rtnl_delete_link net/core/rtnetlink.c:3522 [inline] rtnl_dellink+0x488/0x710 net/core/rtnetlink.c:3564 rtnetlink_rcv_msg+0x7cf/0xb7
_link net/core/rtnetlink.c:3522 [inline] rtnl_dellink+0x488/0x710 net/core/rtnetlink.c:3564 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6955 netlink_rcv_skb+0x219/0x490 net/netlink/af_netlink.c:2534 Calling `PACKET_ADD_MEMBERSHIP` on an ops-locked device can trigger the `NETDEV_UNREGISTER` notifier, which may require disabling promiscuous and/or allmulti mode. Both of these operations require acquiring the netdev instance lock. Move the call to `packet_dev_mc` outside of the RCU critical section. The `mclist` modifications (add, del, flush, unregister) are protected by the RTNL, not the RCU. The RCU only protects the `sklist` and its associated `sks`. The delayed operation on the `mcl
by the RTNL, not the RCU. The RCU only protects the `sklist` and its associated `sks`. The delayed operation on the `mclist` entry remains within the RTNL. References: - https://git.kernel.org/stable/c/2dd4781c5af99415ebbd2f7cc763feb109863c05 - https://git.kernel.org/stable/c/d8d85ef0a631df9127f202e6371bb33a0b589952
CVE ID: CVE-2025-38151 State: PUBLISHED Published: 2025-07-03T08:35:55.879Z Last Updated: 2025-11-03T17:34:41.520Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work The cited commit fixed a crash when cma_netevent_callback was called for a cma_id while work on that id from a previous call had not yet started. The work item was re-initialized in the second call, which corrupted the work item currently in the work queue. However, it left a problem when queue_work fails (because the item is still pending in the work queue from a previous call). In this case, cma_id_put
en queue_work fails (because the item is still pending in the work queue from a previous call). In this case, cma_id_put (which is called in the work handler) is therefore not called. This results in a userspace process hang (zombie process). Fix this by calling cma_id_put() if queue_work fails. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/1ac40736c8c4255d8417b937c9715b193f4a87b3 - https://git.kernel.org/stable/c/ac7897c0124066b9705ffca252a3662d54fc0c9b - https://git.kernel.org/stable/c/02e45168e0fd6fdc6f8f7c42c4b500857aa5efb0 - https://git.kernel.org/stable/c/8b05aa3692e45b8249379dc52b14acc6a104d2e5 - https://git.kernel.org/stable/c/92a251
efb0 - https://git.kernel.org/stable/c/8b05aa3692e45b8249379dc52b14acc6a104d2e5 - https://git.kernel.org/stable/c/92a251c3df8ea1991cd9fe00f1ab0cfce18d7711
CVE ID: CVE-2025-38152 State: PUBLISHED Published: 2025-04-18T07:01:31.714Z Last Updated: 2025-11-03T19:58:29.104Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Clear table_sz when rproc_shutdown There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc. When starting rproc with a firmware not have resource table, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will trigger dump, because rproc->
not have resource table, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will trigger dump, because rproc->cache_table is set to NULL during the last stop operation, but rproc->table_sz is still valid. This issue is found on i.MX8MP and i.MX9. Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=
0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/
c_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Clear rproc->table_sz to address the issue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6e66bca8cd51ebedd5d32426906a38e4a3c69c5f - https://git.kernel.org/stable/c/e6015ca453b82ec54aec9682dcc38773948fcc48 - https://git.kernel.org/stable/c/7c6bb82a6f3da6ab2d3fbea039
ernel.org/stable/c/e6015ca453b82ec54aec9682dcc38773948fcc48 - https://git.kernel.org/stable/c/7c6bb82a6f3da6ab2d3fbea03901482231708b98 - https://git.kernel.org/stable/c/2df19f5f6f72da6f6ebab7cdb3a3b9f7686bb476 - https://git.kernel.org/stable/c/8e0fd2a3b9852ac3cf540edb06ccc0153b38b5af - https://git.kernel.org/stable/c/068f6648ff5b0c7adeb6c363fae7fb188aa178fa - https://git.kernel.org/stable/c/efdde3d73ab25cef4ff2d06783b0aad8b093c0e4
CVE ID: CVE-2025-38153 State: PUBLISHED Published: 2025-07-03T08:35:56.526Z Last Updated: 2025-11-03T17:34:43.452Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: fix error handling of usbnet read calls Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 ("net: asix: add proper error handling of usb read errors"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will
et_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/
ude/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was st
e6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 Additional Analyst
ind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8c97655275482ef5384ce0501640630a0fc0f6f4 - https://git.kernel.org/stable/c/11273279012c922f37cfb4dd95d142803fc07b98 - https://git.kernel.org/stable/c/f398d2dfe450ce2c031d10b585448862d74a0501 - https://git.kernel.org/stable/c/acb47a40b5e38be03ef659b7bacdddc592ed73b7 - https://git.kernel.org/stable/c/60790d287c1a1ced3554d4a87c2f27bf299a932a - https://git.kernel.org/stable/c/30a9e834c74e260533b8d0885e3c89f6f32f7993 - https://git.kernel.org/stable/c/7c01863b1c47f040d9674171e77789a423b9b128 - https://
34c74e260533b8d0885e3c89f6f32f7993 - https://git.kernel.org/stable/c/7c01863b1c47f040d9674171e77789a423b9b128 - https://git.kernel.org/stable/c/405b0d610745fb5e84fc2961d9b960abb9f3d107
CVE ID: CVE-2025-38154 State: PUBLISHED Published: 2025-07-03T08:35:57.188Z Last Updated: 2025-11-03T17:34:44.423Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Avoid using sk_socket after free when sending The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected. Race conditions: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock
ock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here ''' The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } ''' Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count
eady wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions. With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/
log thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... ''' Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546 - https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9 - https://git.kernel.org/
fd8046804ca139a5546 - https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9 - https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7 - https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90 - https://git.kernel.org/stable/c/7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987 - https://git.kernel.org/stable/c/8259eb0e06d8f64c700f5fbdb28a5c18e10de291