Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crc
pe1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 7
ware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) G
000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1
bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_
mp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated--- Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d
Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa - https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d - https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21 - https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd - https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c - https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350
CVE ID: CVE-2024-26908 State: REJECTED Published: 2024-04-17T10:27:54.837Z Last Updated: 2024-04-30T08:11:15.076Z Description: No description available.
CVE ID: CVE-2024-26909 State: PUBLISHED Published: 2024-04-17T10:27:55.462Z Last Updated: 2025-05-04T08:59:22.680Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free A recent DRM series purporting to simplify support for "transparent bridges" and handling of probe deferrals ironically exposed a use-after-free issue on pmic_glink_altmode probe deferral. This has manifested itself as the display subsystem occasionally failing to initialise and NULL-pointer dereferences during boot of machines like the Lenovo ThinkPad X13s. Specifically, the dp-hpd bridge is currently regist
dereferences during boot of machines like the Lenovo ThinkPad X13s. Specifically, the dp-hpd bridge is currently registered before all resources have been acquired which means that it can also be deregistered on probe deferrals. In the meantime there is a race window where the new aux bridge driver (or PHY driver previously) may have looked up the dp-hpd bridge and stored a (non-reference-counted) pointer to the bridge which is about to be deallocated. When the display controller is later initialised, this triggers a use-after-free when attaching the bridges: dp -> aux -> dp-hpd (freed) which may, for example, result in the freed bridge failing to attach: [drm:drm_bridge_attach [drm]] *ERRO
dp-hpd (freed) which may, for example, result in the freed bridge failing to attach: [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16 or a NULL-pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... Call trace: drm_bridge_attach+0x70/0x1a8 [drm] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] drm_bridge_attach+0x80/0x1a8 [drm] dp_bridge_init+0xa8/0x15c [msm] msm_dp_modeset_init+0x28/0xc4 [msm] The DRM bridge implementation is clearly fragile and implicitly built on the assumption that bridges may never go away. In this case, the fix is to move the bridge registration in the pmic_glink_
e assumption that bridges may never go away. In this case, the fix is to move the bridge registration in the pmic_glink_altmode driver to after all resources have been looked up. Incidentally, with the new dp-hpd bridge implementation, which registers child devices, this is also a requirement due to a long-standing issue in driver core that can otherwise lead to a probe deferral loop (see commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")). [DB: slightly fixed commit message by adding the word 'commit'] Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2bbd65c6ca567ed8dbbfc4fb945f57ce64bef342 - https:/
CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2bbd65c6ca567ed8dbbfc4fb945f57ce64bef342 - https://git.kernel.org/stable/c/ef45aa2841e15b649e5417fe3d4de395fe462781 - https://git.kernel.org/stable/c/b979f2d50a099f3402418d7ff5f26c3952fb08bb
CVE ID: CVE-2024-26910 State: PUBLISHED Published: 2024-04-17T15:59:21.967Z Last Updated: 2025-05-04T12:55:08.631Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbag
umazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225 - https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05 - https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49 - https://git
8ef702a58e55ec276aad29b4bd97e05 - https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49 - https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c - https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397 - https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb - https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001
CVE ID: CVE-2024-26911 State: PUBLISHED Published: 2024-04-17T15:59:22.597Z Last Updated: 2025-05-04T08:59:25.696Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/buddy: Fix alloc_range() error handling code Few users have observed display corruption when they boot the machine to KDE Plasma or playing games. We have root caused the problem that whenever alloc_range() couldn't find the required memory blocks the function was returning SUCCESS in some of the corner cases. The right approach would be if the total allocated size is less than the required size, the function should return -ENOSPC. Additional Analyst Notes: - CISA
tal allocated size is less than the required size, the function should return -ENOSPC. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/4b59c3fada06e5e8010ef7700689c71986e667a2 - https://git.kernel.org/stable/c/8746c6c9dfa31d269c65dd52ab42fde0720b7d91
CVE ID: CVE-2024-26912 State: PUBLISHED Published: 2024-04-17T15:59:23.223Z Last Updated: 2025-05-04T08:59:26.936Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix several DMA buffer leaks Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads. Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries
_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6190d4c08897d748dd25f0b78267a90aa1694e15 - https://git.kernel.org/stable/c/042b5f83841fbf7ce39474412db3b5e4765a7ea7
CVE ID: CVE-2024-26913 State: PUBLISHED Published: 2024-04-17T15:59:23.852Z Last Updated: 2025-07-11T17:19:39.513Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dcn35 8k30 Underflow/Corruption Issue [why] odm calculation is missing for pipe split policy determination and cause Underflow/Corruption issue. [how] Add the odm calculation. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cdbe0be8874c63bca85b8c38e5b1eecbdd18df31 - https://git.kernel.org/stable/c/faf51b201bc42adf500945732abb6220c707d6f3
CVE ID: CVE-2024-26914 State: PUBLISHED Published: 2024-04-17T15:59:24.453Z Last Updated: 2025-07-11T17:19:40.631Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix incorrect mpc_combine array size [why] MAX_SURFACES is per stream, while MAX_PLANES is per asic. The mpc_combine is an array that records all the planes per asic. Therefore MAX_PLANES should be used as the array size. Using MAX_SURFACES causes array overflow when there are more than 3 planes. [how] Use the MAX_PLANES for the mpc_combine array size. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git
ombine array size. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0bd8ef618a42d7e6ea3f701065264e15678025e3 - https://git.kernel.org/stable/c/39079fe8e660851abbafa90cd55cbf029210661f
CVE ID: CVE-2024-26915 State: PUBLISHED Published: 2024-04-17T15:59:25.079Z Last Updated: 2025-09-16T08:02:33.510Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reset IH OVERFLOW_CLEAR bit Allows us to detect subsequent IH ring buffer overflows as well. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1 - https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2 - https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70 - https://git.kernel.org/stable/c/2827633c9dab6304ec4cd
git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70 - https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d - https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd
CVE ID: CVE-2024-26916 State: PUBLISHED Published: 2024-04-17T15:59:25.711Z Last Updated: 2025-05-04T08:59:37.658Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amd: flush any delayed gfxoff on suspend entry" commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks") caused GFXOFF control to be used more heavily and the codepath that was removed from commit 0dee72639533 ("drm/amd: flush any delayed gfxoff on suspend entry") now can be exercised at suspend again. Users report that by using GNOME to suspend the lockscreen trigger will cause SDMA traffic and the system can deadlock. This reverts comm
by using GNOME to suspend the lockscreen trigger will cause SDMA traffic and the system can deadlock. This reverts commit 0dee726395333fea833eaaf838bc80962df886c8. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/65158edb0a3a8df23197d52cd24287e39eaf95d6 - https://git.kernel.org/stable/c/ff70e6ff6fc2413caf33410af7462d1f584d927e - https://git.kernel.org/stable/c/caa2565a2e13899be31f7b1e069e6465d3e2adb0 - https://git.kernel.org/stable/c/d855ceb6a5fde668c5431156bc60fae0cc52b764 - https://git.kernel.org/stable/c/916361685319098f696b798ef1560f69ed96e934
CVE ID: CVE-2024-26917 State: PUBLISHED Published: 2024-04-17T15:59:26.340Z Last Updated: 2025-05-04T12:55:09.699Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock" This reverts commit 1a1975551943f681772720f639ff42fbaa746212. This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave". Instead, a work queue should be used, and will be addressed in a separate commit. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b
CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6 - https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b - https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b - https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5 - https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0 - https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783 - https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21 - https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb
CVE ID: CVE-2024-26918 State: PUBLISHED Published: 2024-04-17T15:59:26.954Z Last Updated: 2025-05-04T08:59:40.562Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: Fix active state requirement in PME polling The commit noted in fixes added a bogus requirement that runtime PM managed devices need to be in the RPM_ACTIVE state for PME polling. In fact, only devices in low power states should be polled. However there's still a requirement that the device config space must be accessible, which has implications for both the current state of the polled device and the parent bridge, when present. It's not sufficient to assume the b
for both the current state of the polled device and the parent bridge, when present. It's not sufficient to assume the bridge remains in D0 and cases have been observed where the bridge passes the D0 test, but the PM state indicates RPM_SUSPENDING and config space of the polled device becomes inaccessible during pci_pme_wakeup(). Therefore, since the bridge is already effectively required to be in the RPM_ACTIVE state, formalize this in the code and elevate the PM usage count to maintain the state while polling the subordinate device. This resolves a regression reported in the bugzilla below where a Thunderbolt/USB4 hierarchy fails to scan for an attached NVMe endpoint downstream of a bridge
the bugzilla below where a Thunderbolt/USB4 hierarchy fails to scan for an attached NVMe endpoint downstream of a bridge in a D3hot power state. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/63b1a3d9dd3b3f6d67f524e76270e66767090583 - https://git.kernel.org/stable/c/a4f12e5cbac2865c151d1e97e36eb24205afb23b - https://git.kernel.org/stable/c/41044d5360685e78a869d40a168491a70cdb7e73
CVE ID: CVE-2024-26919 State: PUBLISHED Published: 2024-04-17T15:59:27.581Z Last Updated: 2025-05-04T08:59:41.816Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: Fix debugfs directory leak The ULPI per-device debugfs root is named after the ulpi device's parent, but ulpi_unregister_interface tries to remove a debugfs directory named after the ulpi device itself. This results in the directory sticking around and preventing subsequent (deferred) probes from succeeding. Change the directory name to match the ulpi device. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://gi
ch the ulpi device. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d31b886ed6a5095214062ee4fb55037eb930adb6 - https://git.kernel.org/stable/c/330d22aba17a4d30a56f007d0f51291d7e00862b - https://git.kernel.org/stable/c/33713945cc92ea9c4a1a9479d5c1b7acb7fc4df3 - https://git.kernel.org/stable/c/3caf2b2ad7334ef35f55b95f3e1b138c6f77b368
CVE ID: CVE-2024-26920 State: PUBLISHED Published: 2024-04-17T15:59:28.203Z Last Updated: 2025-05-04T12:55:11.051Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/trigger: Fix to return error if failed to alloc snapshot Fix register_snapshot_trigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/36be97e9eb535fe3008a5cb040b1e56f29f2e398 - https://git.kernel.org/stable/c/6022c065c9ec465d84cebff8f480db083
rg/stable/c/36be97e9eb535fe3008a5cb040b1e56f29f2e398 - https://git.kernel.org/stable/c/6022c065c9ec465d84cebff8f480db083e4ee06b - https://git.kernel.org/stable/c/4b001ef14baab16b553a002cb9979e31b8fc0c6b - https://git.kernel.org/stable/c/0958b33ef5a04ed91f61cef4760ac412080c4e08
CVE ID: CVE-2024-26921 State: PUBLISHED Published: 2024-04-18T09:47:58.632Z Last Updated: 2025-11-03T20:36:57.981Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output
n as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fr
to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enou
ber, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/1b6de5e6575b56502665c65cf93b0ae6aa0f51ab - https://git.kernel.org/stable/c/9705f447bf