Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
e/dev.c:5390 [inline] netif_receive_generic_xdp net/core/dev.c:5431 [inline] do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499 tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f After commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in generic mode"), the original skb may be freed in skb_pp_cow_data() when XDP program was attached, which was allocat
g in generic mode"), the original skb may be freed in skb_pp_cow_data() when XDP program was attached, which was allocated in tun_napi_alloc_frags(). However, the napi->skb still point to the original skb, update it after XDP process. References: - https://git.kernel.org/stable/c/953200d56fc23eebf80a5ad9eed6e2e8a3065093 - https://git.kernel.org/stable/c/1697577e1669b0321d02cd848384a5d33e284296 - https://git.kernel.org/stable/c/1091860a16a86ccdd77c09f2b21a5f634f5ab9ec
CVE ID: CVE-2025-39985 State: PUBLISHED Published: 2025-10-15T07:56:04.439Z Last Updated: 2025-10-15T07:56:04.439Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the mcba_usb driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing,
not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does no
go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on these lines: usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffe
XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow. References: - https://git.kernel.org/stable/c/0fa9303c4b9493727e0d3a6ac3729300e3013930 - https://git.kernel.org/stable/c/37aed407496bf6de8910e588edb04d2435fa7011 - https://git.kernel.org/stable/c/6eec67bfb25637f9b51e584cf59ddace59925bc8 - https://git.kernel.org/stable/c/ca4e51359608e1f29bf1f2c33c3ddf775b6b7ed1 - https://git.kernel.org/stable/c/3664ae91b26d1fd7
ps://git.kernel.org/stable/c/ca4e51359608e1f29bf1f2c33c3ddf775b6b7ed1 - https://git.kernel.org/stable/c/3664ae91b26d1fd7e4cee9cde17301361f4c89d5 - https://git.kernel.org/stable/c/6b9fb82df8868dbe9ffea5874b8d35f951faedbb - https://git.kernel.org/stable/c/b638c3fb0f163e69785ceddb3b434a9437878bec - https://git.kernel.org/stable/c/17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6
CVE ID: CVE-2025-39986 State: PUBLISHED Published: 2025-10-15T07:56:05.143Z Last Updated: 2025-10-15T07:56:05.143Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doin
es not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does
o go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line: dlc = cf->len; Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below wh
e->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below when doing: for (i = 0; i < dlc; i++) writel(cf->data[i], priv->base + (dreg + i * 4)); Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow. References: - https://git.kernel.org/stable/c/063539db42203b29d5aa2adf0cae3d68c646a6b6 - https://git.kernel.org/stable/c/4f382cc887adca8478b9d3e6b81aa6698a95fff4 - https://git.kernel.org/stable/c/60463a1c138900494cb3adae41142a11cd8feb3c - https://git.kernel.org/stable/c/a61ff7ac93270d20ca426c027d6d01c8ac8e9
table/c/60463a1c138900494cb3adae41142a11cd8feb3c - https://git.kernel.org/stable/c/a61ff7ac93270d20ca426c027d6d01c8ac8e904c - https://git.kernel.org/stable/c/2e423e1990f3972cbea779883fef52c2f2acb858 - https://git.kernel.org/stable/c/de77841652e57afbc46e9e1dbf51ee364fc008e1 - https://git.kernel.org/stable/c/7f7b21026a6febdb749f6f6f950427245aa86cce - https://git.kernel.org/stable/c/61da0bd4102c459823fbe6b8b43b01fb6ace4a22
CVE ID: CVE-2025-39987 State: PUBLISHED Published: 2025-10-15T07:56:05.878Z Last Updated: 2025-10-15T07:56:05.878Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing,
not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not
o through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks. This can result in a buffer overflow later on in hi3110_hw_tx() on this line: memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len); Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum
to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow. References: - https://git.kernel.org/stable/c/f2c247e9581024d8b3dd44cbe086bf2bebbef42c - https://git.kernel.org/stable/c/8f351db6b2367991f0736b2cff082f5de4872113 - https://git.kernel.org/stable/c/7ab85762274c0fa997f0ef9a2307b2001aae43c4 - https://git.kernel.org/stable/c/57d332ce8c921d0e340650470bb0c1d707f216ee - https://git.kernel
97f0ef9a2307b2001aae43c4 - https://git.kernel.org/stable/c/57d332ce8c921d0e340650470bb0c1d707f216ee - https://git.kernel.org/stable/c/be1b25005fd0f9d4e78bec6695711ef87ee33398 - https://git.kernel.org/stable/c/def814b4ba31b563584061d6895d5ff447d5bc14 - https://git.kernel.org/stable/c/e77fdf9e33a83a08f04ab0cb68c19ddb365a622f - https://git.kernel.org/stable/c/ac1c7656fa717f29fac3ea073af63f0b9919ec9a
CVE ID: CVE-2025-39988 State: PUBLISHED Published: 2025-10-15T07:56:06.601Z Last Updated: 2025-10-15T07:56:06.601Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the etas_es58x driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by do
does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)); to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function do
e to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, es58x_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN(FD) frame. This can result in a buffer overflow. For example, using the es581.4 variant, the frame will be dispatched to es581_4_tx_can_msg(), go through the last check at the beginning of this function: if (can_is_canfd_skb(skb)) return -EMSGSIZE; and reach this line: memcpy(tx_can_msg->data, cf->data, cf->len); Here, cf->len corresponds to the flags field of
SIZE; and reach this line: memcpy(tx_can_msg->data, cf->data, cf->len); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU or CANFD_MTU (depending on the device capabilities). By fixing the root cause, this prevents the buffer overflow. References: - https://git.kernel.org/stable/c/72de0facc50afdb101fb7197d880407f1abfc77f - https://git.kernel.org/stable/c/c4e582e686c4d683c87f2b4a316385b3d81d370f - https://git.kernel.
1fb7197d880407f1abfc77f - https://git.kernel.org/stable/c/c4e582e686c4d683c87f2b4a316385b3d81d370f - https://git.kernel.org/stable/c/cbc1de71766f326a44bb798aeae4a7ef4a081cc9 - https://git.kernel.org/stable/c/b26cccd87dcddc47b450a40f3b1ac3fe346efcff - https://git.kernel.org/stable/c/e587af2c89ecc6382c518febea52fa9ba81e47c0 - https://git.kernel.org/stable/c/38c0abad45b190a30d8284a37264d2127a6ec303
CVE ID: CVE-2025-39989 State: PUBLISHED Published: 2025-04-18T07:01:39.321Z Last Updated: 2025-05-26T05:25:34.006Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mce: use is_copy_from_user() to determine copy-from-user context Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetch
case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case: Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space. - For instr case: If a poison found while instruction fetching in
M_EXTABLE_FAULT() and return a -EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process
ks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Re
etected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Backgro
does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI fro
ssues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for instr case Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated--- References: - https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e
ed but reported "not ---truncated--- References: - https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e6e4 - https://git.kernel.org/stable/c/3e3d8169c0950a0b3cd5105f6403a78350dcac80 - https://git.kernel.org/stable/c/449413da90a337f343cc5a73070cbd68e92e8a54 - https://git.kernel.org/stable/c/0b8388e97ba6a8c033f9a8b5565af41af07f9345 - https://git.kernel.org/stable/c/1a15bb8303b6b104e78028b6c68f76a0d4562134
CVE ID: CVE-2025-39990 State: PUBLISHED Published: 2025-10-15T07:56:07.295Z Last Updated: 2025-10-15T07:56:07.295Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Check the helper function is valid in get_helper_proto kernel test robot reported verifier bug [1] where the helper func pointer could be NULL due to disabled config option. As Alexei suggested we could check on that in get_helper_proto directly. Marking tail_call helper func with BPF_PTR_POISON, because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com References: - https://git.kernel.org/stable/c/3d429cb1278e995e22995
ernel.org/oe-lkp/202507160818.68358831-lkp@intel.com References: - https://git.kernel.org/stable/c/3d429cb1278e995e22995ef117fa96d223a67e93 - https://git.kernel.org/stable/c/6233715b4b714068d6c831d214a4e8792109875a - https://git.kernel.org/stable/c/e4414b01c1cd9887bbde92f946c1ba94e40d6d64
CVE ID: CVE-2025-39991 State: PUBLISHED Published: 2025-10-15T07:58:17.257Z Last Updated: 2025-10-15T07:58:17.257Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. References: - https://git.kernel.org/stable/c/1f52119809b76d43759fc47da1cf708690b740a1 - https://git.kernel.org/stable/c/888830b2cbc035838bebefe94502976da9433
table/c/1f52119809b76d43759fc47da1cf708690b740a1 - https://git.kernel.org/stable/c/888830b2cbc035838bebefe94502976da94332a5 - https://git.kernel.org/stable/c/500fcc31e488d798937a23dbb1f62db46820c5b2 - https://git.kernel.org/stable/c/3fd2ef2ae2b5c955584a3bee8e83ae7d7a98f782
CVE ID: CVE-2025-39992 State: PUBLISHED Published: 2025-10-15T07:58:17.927Z Last Updated: 2025-10-15T07:58:17.927Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PT
dress. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during
kip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this is
mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue. References: - https://git.kernel.org/stable/c/4e5f060d7347466f77aaff1c0d5a6c4f1fb217ac - https://git.kernel.org/stable/c/9cddad3b26dac830407d2d3c0de5205ff6d6dda0 - https://git.kernel.org/stable/c/e4e99d69b8b8295c501b2eef89e13306b738b667 - https://git.kernel.org/stable/c/1367da7eb875d01102d2ed18654b24d261ff5393