Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
0. Then the value is converted to int, and only after that is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while the lower 32 bits are zero. Furthermore, it is best to return EINVAL immediately upon seeing the invalid user input. The WARNING is insufficient to prevent further undefined behavior based on other invalid user input. All checks of the input value should be applied to the original variable call_pkg->nd_family. [iweiny: update commit message] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4b65cff06a004ac54f6ea8886060f0d07b1ca055 - https://git
Program Container: References: - https://git.kernel.org/stable/c/4b65cff06a004ac54f6ea8886060f0d07b1ca055 - https://git.kernel.org/stable/c/92ba06aef65522483784dcbd6697629ddbd4c4f9 - https://git.kernel.org/stable/c/bae5b55e0f327102e78f6a66fb127275e9bc91b6 - https://git.kernel.org/stable/c/c90402d2a226ff7afbe1d0650bee8ecc15a91049 - https://git.kernel.org/stable/c/e71a57c5aaa389d4c3c82f920761262efdd18d38 - https://git.kernel.org/stable/c/73851cfceb00cc77d7a0851bc10f2263394c3e87 - https://git.kernel.org/stable/c/85f11291658ab907c4294319c8102450cc75bb96 - https://git.kernel.org/stable/c/2ff0e408db36c21ed3fa5e3c1e0e687c82cf132f
CVE ID: CVE-2025-22045 State: PUBLISHED Published: 2025-04-16T14:12:05.849Z Last Updated: 2025-11-03T19:41:30.092Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimization
comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be maki
ntly under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be making the impact of this a lot worse. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/618d5612ecb7bfc1c85342daafeb2b47e29e77a3 - https://git.kernel.org/stable/c/556d446068f90981e5d71ca686bdaccdd545d491 - https://git.kernel.org/stable/c/0a8f806ea6b5dd64b3d1f05ff774817d5f7ddbd1 - https://git.kernel.org/stable/c/0708fd6bd8161871bfbadced2ca4319b84ab44fe - https://git.kernel.org/stable/c/7085895c59e4057ffae17f58990ccb630087d0d2 - https://git.kernel.org/stable/c/93224deb50a8d20df3884f3672ce9f982129aa50 - https://git.kernel.org/stable/
cb630087d0d2 - https://git.kernel.org/stable/c/93224deb50a8d20df3884f3672ce9f982129aa50 - https://git.kernel.org/stable/c/320ac1af4c0bdb92c864dc9250d1329234820edf - https://git.kernel.org/stable/c/78d6f9a9eb2a5da6fcbd76d6191d24b0dcc321be - https://git.kernel.org/stable/c/3ef938c3503563bfc2ac15083557f880d29c2e64
CVE ID: CVE-2025-22046 State: PUBLISHED Published: 2025-04-16T14:12:06.454Z Last Updated: 2025-05-26T05:17:17.791Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: uprobes/x86: Harden uretprobe syscall trampoline check Jann reported a possible issue when trampoline_check_ip returns address near the bottom of the address space that is allowed to call into the syscall if uretprobes are not set up: https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf Though the mmap minimum address restrictions will typically prevent creating mappings there, let's make sure uretprobe syscall check
map minimum address restrictions will typically prevent creating mappings there, let's make sure uretprobe syscall checks for that. References: - https://git.kernel.org/stable/c/c35771342e47d58ab9433f3be1c3c30f2c5fa4f3 - https://git.kernel.org/stable/c/b0065d712049c87e1994c6eac00c6a637e39b325 - https://git.kernel.org/stable/c/d4e48b8d59fe162938a5004ace698c847e6a3207 - https://git.kernel.org/stable/c/fa6192adc32f4fdfe5b74edd5b210e12afd6ecc0
CVE ID: CVE-2025-22047 State: PUBLISHED Published: 2025-04-16T14:12:07.061Z Last Updated: 2025-05-26T05:17:19.094Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/microcode/AMD: Fix __apply_microcode_amd()'s return value When verify_sha256_digest() fails, __apply_microcode_amd() should propagate the failure by returning false (and not -1 which is promoted to true). References: - https://git.kernel.org/stable/c/763f4d638f71cb45235395790a46e9f9e84227fd - https://git.kernel.org/stable/c/ada88219d5315fc13f2910fe278c7112d8d68889 - https://git.kernel.org/stable/c/d295c58fad1d5ab987a81f139dd21498732c4f13 - https://git.kernel.org/st
e278c7112d8d68889 - https://git.kernel.org/stable/c/d295c58fad1d5ab987a81f139dd21498732c4f13 - https://git.kernel.org/stable/c/7f705a45f130a85fbf31c2abdc999c65644c8307 - https://git.kernel.org/stable/c/31ab12df723543047c3fc19cb8f8c4498ec6267f
CVE ID: CVE-2025-22048 State: PUBLISHED Published: 2025-04-16T14:12:07.679Z Last Updated: 2025-05-26T05:17:20.353Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Don't override subprog's return value The verifier test `calls: div by 0 in subprog` triggers a panic at the ld.bu instruction. The ld.bu insn is trying to load byte from memory address returned by the subprog. The subprog actually set the correct address at the a5 register (dedicated register for BPF return values). But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in Loon
59d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in LoongArch). For function call insn, we later propagate the a0 register back to a5 register. This is right for native calls but wrong for bpf2bpf calls which expect zero-extended return value in a5 register. So only move a0 to a5 for native calls (i.e. non-BPF_PSEUDO_CALL). References: - https://git.kernel.org/stable/c/7df2696256a034405d3c5a71b3a4c54725de4404 - https://git.kernel.org/stable/c/223d565d8892481684091cfbaf3466f2b0e289d3 - https://git.kernel.org/stable/c/780628a780b622759d9e5adc76d15432144da1a3 - https://git.kernel.org/stable/c/996e90ab446641553e8e21707b38b9709605e0e
ble/c/780628a780b622759d9e5adc76d15432144da1a3 - https://git.kernel.org/stable/c/996e90ab446641553e8e21707b38b9709605e0e0 - https://git.kernel.org/stable/c/60f3caff1492e5b8616b9578c4bedb5c0a88ed14
CVE ID: CVE-2025-22049 State: PUBLISHED Published: 2025-04-16T14:12:08.317Z Last Updated: 2025-11-03T19:41:31.511Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Increase ARCH_DMA_MINALIGN up to 16 ARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices (such as APBDMA) require 16 bytes alignment. When the data buffer length is too small, the hardware may make an error writing cacheline. Thus, it is dangerous to allocate a small memory buffer for DMA. It's always safe to define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16.
MA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f39af67f03b564b763b06e44cb960c10a382d54a - https://git.kernel.org/stable/c/279ec25c2df49fba1cd9488f2ddd045d9cb2112e - https://git.kernel.org/stable/c/1d0def2d1658666ec1f32c9495df60e7411e3c82 - https://git.kernel.org/stable/c/bfff341cac7c650e6ca8d10503725992f5564d0f - https://git.kernel.org/stable/c/8b82aea3666f8f2c78f86148d78aea99c46e0f82 - https://git.kernel.org/stable/c/4103cfe9dcb88010ae4911d3ff417457d1b6a720
CVE ID: CVE-2025-22050 State: PUBLISHED Published: 2025-04-16T14:12:08.954Z Last Updated: 2025-11-03T19:41:32.888Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usbnet:fix NPE during rx_complete Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check. This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued. Subsequent processes: (e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference
., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/95789c2f94fd29dce8759f9766baa333f749287c - https://git.kernel.org/stable/c/0f10f83acfd619e13c64d6705908dfd792f19544 - https://git.kernel.org/stable/c/acacd48a37b52fc95f621765762c04152b58d642 - https://git.kernel.org/stable/c/d689645cd1594ea1d13cb0c404f8ad1011353e0e - https://git.kernel.org/stable/c/0c30988588b28393e3e8873d5654f910e86391ba - https://git.kernel.org/stable/c/fd9ee3f0d6a53844f65efde581c91bbb0ff749ac - https://git.kernel.org/stable/c/51de3600093429e3b
s://git.kernel.org/stable/c/fd9ee3f0d6a53844f65efde581c91bbb0ff749ac - https://git.kernel.org/stable/c/51de3600093429e3b712e5f091d767babc5dd6df
CVE ID: CVE-2025-22051 State: PUBLISHED Published: 2025-04-16T14:12:09.761Z Last Updated: 2025-10-30T14:33:33.358Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: gpib: Fix Oops after disconnect in agilent usb If the agilent usb dongle is disconnected subsequent calls to the driver cause a NULL dereference Oops as the bus_interface is set to NULL on disconnect. This problem was introduced by setting usb_dev from the bus_interface for dev_xxx messages. Previously bus_interface was checked for NULL only in the functions directly calling usb_fill_bulk_urb or usb_control_msg. Check for valid bus_interface on all interface e
in the functions directly calling usb_fill_bulk_urb or usb_control_msg. Check for valid bus_interface on all interface entry points and return -ENODEV if it is NULL. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e88633705078f40391a9afc6cc8ea3025e6f692b - https://git.kernel.org/stable/c/50ef6e45bec79da4c5a01fad4dc23466ba255099 - https://git.kernel.org/stable/c/8491e73a5223acb0a4b4d78c3f8b96aa9c5e774d
CVE ID: CVE-2025-22052 State: PUBLISHED Published: 2025-04-16T14:12:10.412Z Last Updated: 2025-10-30T14:33:46.116Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: gpib: Fix Oops after disconnect in ni_usb If the usb dongle is disconnected subsequent calls to the driver cause a NULL dereference Oops as the bus_interface is set to NULL on disconnect. This problem was introduced by setting usb_dev from the bus_interface for dev_xxx messages. Previously bus_interface was checked for NULL only in the the functions directly calling usb_fill_bulk_urb or usb_control_msg. Check for valid bus_interface on all interface entry poin
nctions directly calling usb_fill_bulk_urb or usb_control_msg. Check for valid bus_interface on all interface entry points and return -ENODEV if it is NULL. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b2d8d7959077c5d4b11d0dc6bd2167791fd1c72e - https://git.kernel.org/stable/c/5dc98ba6f7304c188b267ef481281849638447bf - https://git.kernel.org/stable/c/a239c6e91b665f1837cf57b97fe638ef1baf2e78
CVE ID: CVE-2025-22053 State: PUBLISHED Published: 2025-04-16T14:12:11.034Z Last Updated: 2025-05-26T05:17:26.705Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ibmveth: make veth_pool_store stop hanging v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable. Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this
: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this easily with a little shell script. This causes a hang. I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 2
4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c
Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c
ble+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_comm
] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_
kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243. ---truncated--- References: - https://git.kernel.org/stable/c/1e458c292f4c687dcf5aad32dd4836d03cd2191f - https://git.kernel.org/stable/c/8a88bb092f4208355880b9fdcc69d491aa297595 - https://git.kernel.org/stable/c/86cc70f5c85dc09bf7f3e1eee380eefe73c90765 - https://git.kernel.org/stable/c/0a2470e3ecde64fc7e37
/git.kernel.org/stable/c/86cc70f5c85dc09bf7f3e1eee380eefe73c90765 - https://git.kernel.org/stable/c/0a2470e3ecde64fc7e3781dc474923193621ae67 - https://git.kernel.org/stable/c/053f3ff67d7feefc75797863f3d84b47ad47086f
CVE ID: CVE-2025-22054 State: PUBLISHED Published: 2025-04-16T14:12:11.849Z Last Updated: 2025-11-03T19:41:35.650Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arcnet: Add NULL check in com20020pci_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, com20020pci_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/661cf5d102949898c931e81fd4e1c773afc
Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/661cf5d102949898c931e81fd4e1c773afcdeafa - https://git.kernel.org/stable/c/905a34dc1ad9a53a8aaaf8a759ea5dbaaa30418d - https://git.kernel.org/stable/c/ef8b29398ea6061ac8257f3e45c9be45cc004ce2 - https://git.kernel.org/stable/c/be8a0decd0b59a52a07276f9ef3b33ef820b2179 - https://git.kernel.org/stable/c/ececf8eff6c25acc239fa8f0fd837c76bc770547 - https://git.kernel.org/stable/c/ebebeb58d48e25525fa654f2c53a24713fe141c3 - https://git.kernel.org/stable/c/a654f31b33515d39bb56c75fd8b26bef025ced7e - https://git.kernel.org/stable/c/887226163504494ea7e58033a97c2d2ab12e05d4 - https://git.kernel.org/stable/c/fda8c491db2a90f
tps://git.kernel.org/stable/c/887226163504494ea7e58033a97c2d2ab12e05d4 - https://git.kernel.org/stable/c/fda8c491db2a90ff3e6fbbae58e495b4ddddeca3
CVE ID: CVE-2025-22055 State: PUBLISHED Published: 2025-04-16T14:12:12.595Z Last Updated: 2025-11-03T19:41:38.411Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: fix geneve_opt length integer overflow struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes. However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to *fake* a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read. One example crash log is like below: [ 3.905425] =======
use the parsing logic, further achieve heap out-of-bounds read. One example crash log is like below: [ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check
ump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0x
0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000
000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Fix these issues by enforing correct length condition in related policies. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a2cb85f989e2074e2f392e00188c438cab3de088 - https://git.kernel.org/stable/c/b4513ad0f391871d3feee8ddf535609a3aabeeac - htt
2cb85f989e2074e2f392e00188c438cab3de088 - https://git.kernel.org/stable/c/b4513ad0f391871d3feee8ddf535609a3aabeeac - https://git.kernel.org/stable/c/21748669c5825761cbbf47cbeeb01387ddccc8cb - https://git.kernel.org/stable/c/5a2976cc4d9c36ff58a0f10e35ce4283cbaa9c0e - https://git.kernel.org/stable/c/2952776c69a1a551649ed770bf22e3f691f6ec65 - https://git.kernel.org/stable/c/738ae5712215fe9181587d582b23333f02c62ca6 - https://git.kernel.org/stable/c/4d606069bdd3c76f8ab1f06796c97ef7f4746807 - https://git.kernel.org/stable/c/b27055a08ad4b415dcf15b63034f9cb236f7fb40
CVE ID: CVE-2025-22056 State: PUBLISHED Published: 2025-04-16T14:12:13.440Z Last Updated: 2025-11-03T19:41:41.225Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix geneve_opt type confusion addition When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *. However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write. [ 6.989857] ===================