Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ere create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes
ded rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2 - https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423 - https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801 - https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff
g/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801 - https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64 - https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f - https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0 - https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d - https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453
CVE ID: CVE-2024-35961 State: PUBLISHED Published: 2024-05-20T09:41:52.551Z Last Updated: 2025-05-04T09:09:17.831Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Register devlink first under devlink lock In case device is having a non fatal FW error during probe, the driver will report the error to user via devlink. This will trigger a WARN_ON, since mlx5 is calling devlink_register() last. In order to avoid the WARN_ON[1], change mlx5 to invoke devl_register() first under devlink lock. [1] WARNING: CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0 CPU: 5 PID: 227 Comm: kworker/u
CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0 CPU: 5 PID: 227 Comm: kworker/u16:3 Not tainted 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core] RIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0 Call Trace: <TASK> ? __warn+0x79/0x120 ? devlink_recover_notify.constprop.0+0xb8/0xc0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? devlink_recover_notify.constprop.0+0xb8/0xc0 devlink_health_report+0x4a/0x1
p+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? devlink_recover_notify.constprop.0+0xb8/0xc0 devlink_health_report+0x4a/0x1c0 mlx5_fw_reporter_err_work+0xa4/0xd0 [mlx5_core] process_one_work+0x1bb/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x4d/0x3c0 ? process_one_work+0x3c0/0x3c0 kthread+0xc6/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8c91c60858473731bcdaf04fda99fcbcf84420d4 - https://git.kernel.org/stable/c/967caa3d37c078e5b95a32094657e6a4cad145f0 - https://git.kernel.org/stable/c/c6e77aa9dd82bc18a89bf49418f8f7e961cfccc8
CVE ID: CVE-2024-35962 State: PUBLISHED Published: 2024-05-20T09:41:53.207Z Last Updated: 2025-05-04T09:09:19.304Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: complete validation of user input In my recent commit, I missed that do_replace() handlers use copy_from_sockptr() (which I fixed), followed by unsafe copy_from_sockptr_offset() calls. In all functions, we can perform the @optlen validation before even calling xt_alloc_table_info() with the following check: if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL; Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: -
sizeof(tmp)) return -EINVAL; Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cf4bc359b76144a3dd55d7c09464ef4c5f2b2b05 - https://git.kernel.org/stable/c/97dab36e57c64106e1c8ebd66cbf0d2d1e52d6b7 - https://git.kernel.org/stable/c/c760089aa98289b4b88a7ff5a62dd92845adf223 - https://git.kernel.org/stable/c/89242d9584c342cb83311b598d9e6b82572eadf8 - https://git.kernel.org/stable/c/562b7245131f6e9f1d280c8b5a8750f03edfc05c - https://git.kernel.org/stable/c/65acf6e0501ac8880a4f73980d01b5d27648b956
CVE ID: CVE-2024-35963 State: PUBLISHED Published: 2024-05-20T09:41:53.861Z Last Updated: 2025-11-03T21:55:05.767Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/781f3a97a38a338bc893b6db7f9f9670bf1a9e37 - https://git.kernel.org/stable/c/0c18a64039aa3f1c16f208d197c65076da798137 - https://git.kernel.org/stable/c/50173882bb187e70e37bac01385b9b114019bee2 - https://git.kernel.org/stable/c/b2186061d6043d6345a
//git.kernel.org/stable/c/50173882bb187e70e37bac01385b9b114019bee2 - https://git.kernel.org/stable/c/b2186061d6043d6345a97100460363e990af0d46
CVE ID: CVE-2024-35964 State: PUBLISHED Published: 2024-05-20T09:41:54.513Z Last Updated: 2025-11-03T21:55:07.388Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not validating setsockopt user input Check user input length before copying data. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cec736e60dc18d91b88af28d96664bff284b02d1 - https://git.kernel.org/stable/c/6a6baa1ee7a9df33adbf932305053520b9741b35 - https://git.kernel.org/stable/c/0c4a89f4690478969729c7ba5f69d53d8516aa12 - https://git.kernel.org/stable/c/9e8742cdfc4b0e65266bb4a9
.kernel.org/stable/c/0c4a89f4690478969729c7ba5f69d53d8516aa12 - https://git.kernel.org/stable/c/9e8742cdfc4b0e65266bb4a901a19462bda9285e
CVE ID: CVE-2024-35965 State: PUBLISHED Published: 2024-05-20T09:41:55.171Z Last Updated: 2025-11-03T20:37:39.951Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f13b04cf65a86507ff15a9bbf37969d25be3e2a0 - https://git.kernel.org/stable/c/9d42f373391211c7c8af66a3a316533a32b8a607 - https://git.kernel.org/stable/c/28234f8ab69c522ba447f3e041bbfbb284c5959a - https://git.kernel.org/stable/c/8ee0c132a61df9723813c4
it.kernel.org/stable/c/28234f8ab69c522ba447f3e041bbfbb284c5959a - https://git.kernel.org/stable/c/8ee0c132a61df9723813c40e742dc5321824daa9 - https://git.kernel.org/stable/c/4f3951242ace5efc7131932e2e01e6ac6baed846
CVE ID: CVE-2024-35966 State: PUBLISHED Published: 2024-05-20T09:41:55.838Z Last Updated: 2025-11-03T21:55:08.869Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds
lab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d072ea24748189cd8f4a9c3f585ca9af073a0838 - https://git.kernel.org/stable/c/00767fbd67af70d7a550caa5b12d9515fa978bab - https://git.kernel.org/stable/c/eea40d33bf936a5c7fb03c190e61e0cfee00e872 - https://git.kernel.org/stable/c/4ea65e2095e9bd151d0469328dd7fc2858feb546 - https://git.kernel.org/stable/c/c3f787a3eafe519c93d
//git.kernel.org/stable/c/4ea65e2095e9bd151d0469328dd7fc2858feb546 - https://git.kernel.org/stable/c/c3f787a3eafe519c93df9abbb0ca5145861c8d0f - https://git.kernel.org/stable/c/a97de7bff13b1cc825c1b1344eaed8d6c2d3e695
CVE ID: CVE-2024-35967 State: PUBLISHED Published: 2024-05-20T09:41:56.503Z Last Updated: 2025-05-04T09:09:25.456Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-e
-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b0e30c37695b614bee69187f86eaf250e36606ce - https://git.kernel.org/stable/c/2c2dc87cdebef3fe3b9d7a711a984c70e376e32e - https://git.kernel.org/stable/c/7bc65d23ba20dcd7ecc094a12c181e594e5eb315 - https://git.kernel.org/stable/c/72473db90900da970a16ee50ad23c2c38d107d8c - https://git.kernel.org/stable/c/419a0ffca7010216f0fc265b08558d7394fa0ba7 - https://git.kernel.org/stable/c/51eda36d33e43201e7a4fd35232e069b2c850b01
CVE ID: CVE-2024-35968 State: PUBLISHED Published: 2024-05-20T09:41:57.162Z Last Updated: 2025-05-04T09:09:26.795Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pds_core: Fix pdsc_check_pci_health function to use work thread When the driver notices fw_status == 0xff it tries to perform a PCI reset on itself via pci_reset_function() in the context of the driver's health thread. However, pdsc_reset_prepare calls pdsc_stop_health_thread(), which attempts to stop/flush the health thread. This results in a deadlock because the stop/flush will never complete since the driver called pci_reset_function() from the health thread context
k because the stop/flush will never complete since the driver called pci_reset_function() from the health thread context. Fix by changing the pdsc_check_pci_health_function() to queue a newly introduced pdsc_pci_reset_thread() on the pdsc's work queue. Unloading the driver in the fw_down/dead state uncovered another issue, which can be seen in the following trace: WARNING: CPU: 51 PID: 6914 at kernel/workqueue.c:1450 __queue_work+0x358/0x440 [...] RIP: 0010:__queue_work+0x358/0x440 [...] Call Trace: <TASK> ? __warn+0x85/0x140 ? __queue_work+0x358/0x440 ? report_bug+0xfc/0x1e0 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __queue_work+0x358/0x440 queue_wor
e0 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __queue_work+0x358/0x440 queue_work_on+0x28/0x30 pdsc_devcmd_locked+0x96/0xe0 [pds_core] pdsc_devcmd_reset+0x71/0xb0 [pds_core] pdsc_teardown+0x51/0xe0 [pds_core] pdsc_remove+0x106/0x200 [pds_core] pci_device_remove+0x37/0xc0 device_release_driver_internal+0xae/0x140 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xa0 pdsc_cleanup_module+0x10/0x780 [pds_core] __x64_sys_delete_module+0x142/0x2b0 ? syscall_trace_enter.isra.18+0x126/0x1a0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fbd9d03a14b [...] Fix this by preventing the devcmd reset if the
0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fbd9d03a14b [...] Fix this by preventing the devcmd reset if the FW is not running. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/38407914d48273d7f8ab765b9243658afe1c3ab6 - https://git.kernel.org/stable/c/81665adf25d28a00a986533f1d3a5df76b79cad9
CVE ID: CVE-2024-35969 State: PUBLISHED Published: 2024-05-20T09:41:57.858Z Last Updated: 2025-05-04T09:09:27.884Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it still means hlist_for_each_entry_rcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane. In particular, the reference count can be zero. This can happen if ipv6_del_addr is called in parallel. ipv6_del_addr removes
ticular, the reference count can be zero. This can happen if ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough timing, this can happen: 1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry. 2. Then, the whole ipv6_del_addr is executed for the given entry. The reference count drops to zero and kfree_rcu is scheduled. 3. ipv6_get_ifaddr continues and tries to increments the reference count (in6_ifa_hold). 4. The rcu is unlocked and the entry is freed. 5. The freed entry is returned. Prevent increasing of the reference count in
The rcu is unlocked and the entry is freed. 5. The freed entry is returned. Prevent increasing of the reference count in such case. The name in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe. [ 41.506330] refcount_t: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad
09163] RIP: 0010:refcount_warn_saturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: f
0000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? __warn+0x7b/0x120 [ 41.517535] ? refcount_warn_saturate+0xa5/0x130 [ 41.517923] ? report_bug+0x164/0x190 [ 41.518240
] ? __warn+0x7b/0x120 [ 41.517535] ? refcount_warn_saturate+0xa5/0x130 [ 41.517923] ? report_bug+0x164/0x190 [ 41.518240] ? handle_bug+0x3d/0x70 [ 41.518541] ? exc_invalid_op+0x17/0x70 [ 41.520972] ? asm_exc_invalid_op+0x1a/0x20 [ 41.521325] ? refcount_warn_saturate+0xa5/0x130 [ 41.521708] ipv6_get_ifaddr+0xda/0xe0 [ 41.522035] inet6_rtm_getaddr+0x342/0x3f0 [ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10 [ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0 [ 41.523102] ? netlink_unicast+0x30f/0x390 [ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 41.523832] netlink_rcv_skb+0x53/0x100 [ 41.524157] netlink_unicast+0x23b/0x390 [ 41.524484] netlink_sendmsg+0x1f2/0x440 [ 41.524826] __sys_sendto+0x1d8/0x
100 [ 41.524157] netlink_unicast+0x23b/0x390 [ 41.524484] netlink_sendmsg+0x1f2/0x440 [ 41.524826] __sys_sendto+0x1d8/0x1f0 [ 41.525145] __x64_sys_sendto+0x1f/0x30 [ 41.525467] do_syscall_64+0xa5/0x1b0 [ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1db
CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1 - https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903 - https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70 - https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb - https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb - https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652 - https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f438bb83 - https://git.kernel.org/stable/c/7633c4da919ad51164acbf1aa322cc1a3ead6129
CVE ID: CVE-2024-35970 State: PUBLISHED Published: 2024-05-20T09:41:58.524Z Last Updated: 2025-05-04T09:09:29.452Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG
c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAP
, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear
return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded fr
fter traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153 - https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9 - https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea
el.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9 - https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6 - https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf - https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e
CVE ID: CVE-2024-35971 State: PUBLISHED Published: 2024-05-20T09:41:59.174Z Last Updated: 2025-05-04T09:09:30.620Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Handle softirqs at the end of IRQ thread to fix hang The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, t
ding. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below: ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_w