Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-21766 State: PUBLISHED Published: 2025-02-27T02:18:16.570Z Last Updated: 2025-11-03T19:37:21.502Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ce3c6165fce0f06305c806696882a3ad4b90e33f - https://git.kernel.org/stable/c/ea07480b23225942208f1b754fea1e7ec486d37e - https://git.kernel.org/stable/c/9b1766d1ff5fe496aabe9fc5f4e34e53f35c11c4 - https://git.kernel.org/stab
fea1e7ec486d37e - https://git.kernel.org/stable/c/9b1766d1ff5fe496aabe9fc5f4e34e53f35c11c4 - https://git.kernel.org/stable/c/4583748b65dee4d61bd50a2214715b4237bc152a - https://git.kernel.org/stable/c/a39f61d212d822b3062d7f70fa0588e50e55664e - https://git.kernel.org/stable/c/139512191bd06f1b496117c76372b2ce372c9a41
CVE ID: CVE-2025-21767 State: PUBLISHED Published: 2025-02-27T02:18:17.067Z Last Updated: 2025-11-03T19:37:24.318Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context The following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0
h: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context. Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context
is problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d9c217fadfcff7a8df58567517d1e4253f3fd243 - https://git.kernel.org/stable/c/60f54f0d4ea530950549a8263e6fdd70a40490a4 - https://git.kernel.org/stable/c/852805b6cbdb69c298a8fc9fbe79994c95106e04 - https://git.kernel.org/stable/c/8783ceeee797d9aa9cfe150690fb9d0bac8cc459 - https://git.kernel.org/stable/c/cc3d79e7c806cb57
ps://git.kernel.org/stable/c/8783ceeee797d9aa9cfe150690fb9d0bac8cc459 - https://git.kernel.org/stable/c/cc3d79e7c806cb57d71c28a4a35e7d7fb3265faa - https://git.kernel.org/stable/c/0fb534187d2355f6c8f995321e76d1ccd1262ac1 - https://git.kernel.org/stable/c/6bb05a33337b2c842373857b63de5c9bf1ae2a09
CVE ID: CVE-2025-21768 State: PUBLISHED Published: 2025-02-27T02:18:17.553Z Last Updated: 2025-05-04T07:20:42.186Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels Some lwtunnels have a dst cache for post-transformation dst. If the packet destination did not change we may end up recording a reference to the lwtunnel in its own cache, and the lwtunnel state will never be freed. Discovered by the ioam6.sh test, kmemleak was recently fixed to catch per-cpu memory leaks. I'm not sure if rpl and seg6 can actually hit this, but in principle I don't see why not. References: -
pu memory leaks. I'm not sure if rpl and seg6 can actually hit this, but in principle I don't see why not. References: - https://git.kernel.org/stable/c/5ab11a4e219e93b8b31a27f8ec98d42afadd8b7a - https://git.kernel.org/stable/c/4c0f200c7d06fedddde82209c099014d63f4a6c0 - https://git.kernel.org/stable/c/92191dd1073088753821b862b791dcc83e558e07
CVE ID: CVE-2025-21769 State: PUBLISHED Published: 2025-02-27T02:18:18.059Z Last Updated: 2025-10-01T19:36:40.856Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ptp: vmclock: Add .owner to vmclock_miscdev_fops Without the .owner field, the module can be unloaded while /dev/vmclock0 is open, leading to an oops. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/3b5709225b43ee33e1026dd1fc0949a7f19b5289 - https://git.kernel.org/stable/c/7b07b040257c1b658ef3eca86e4b6ae02d65069c
CVE ID: CVE-2025-21770 State: PUBLISHED Published: 2025-02-27T02:18:18.570Z Last Updated: 2025-10-01T19:36:40.725Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu: Fix potential memory leak in iopf_queue_remove_device() The iopf_queue_remove_device() helper removes a device from the per-iommu iopf queue when PRI is disabled on the device. It responds to all outstanding iopf's with an IOMMU_PAGE_RESP_INVALID code and detaches the device from the queue. However, it fails to release the group structure that represents a group of iopf's awaiting for a response after responding to the hardware. This can cause a memory leak if i
represents a group of iopf's awaiting for a response after responding to the hardware. This can cause a memory leak if iopf_queue_remove_device() is called with pending iopf's. Fix it by calling iopf_free_group() after the iopf group is responded. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/db60d2d896a17decd58d143eef92cf22eb0a0176 - https://git.kernel.org/stable/c/90d5429cd2921ca2714684ed525898d431bb9283 - https://git.kernel.org/stable/c/9759ae2cee7cd42b95f1c48aa3749bd02b5ddb08
CVE ID: CVE-2025-21771 State: PUBLISHED Published: 2025-02-27T02:18:19.050Z Last Updated: 2025-05-04T07:20:45.331Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix incorrect autogroup migration detection scx_move_task() is called from sched_move_task() and tells the BPF scheduler that cgroup migration is being committed. sched_move_task() is used by both cgroup and autogroup migrations and scx_move_task() tried to filter out autogroup migrations by testing the destination cgroup and PF_EXITING but this is not enough. In fact, without explicitly tagging the thread which is doing the cgroup migration, there is no goo
this is not enough. In fact, without explicitly tagging the thread which is doing the cgroup migration, there is no good way to tell apart scx_move_task() invocations for racing migration to the root cgroup and an autogroup migration. This led to scx_move_task() incorrectly ignoring a migration from non-root cgroup to an autogroup of the root cgroup triggering the following warning: WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340 ... Call Trace: <TASK> cgroup_migrate_execute+0x5b1/0x700 cgroup_attach_task+0x296/0x400 __cgroup_procs_write+0x128/0x140 cgroup_procs_write+0x17/0x30 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x31d/0x4a0 __x64_sys_write+0x72/0
+0x128/0x140 cgroup_procs_write+0x17/0x30 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x31d/0x4a0 __x64_sys_write+0x72/0xf0 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it by adding an argument to sched_move_task() that indicates whether the moving is for a cgroup or autogroup migration. After the change, scx_move_task() is called only for cgroup migrations and renamed to scx_cgroup_move_task(). References: - https://git.kernel.org/stable/c/75bf2f80c046d2ec5a07455891ea0a9fb6d8b5f6 - https://git.kernel.org/stable/c/d8b510d0ddc65d8a71e0f9a3acc9ed5f010fc514 - https://git.kernel.org/stable/c/d6f3e7d564b2309e1f17e709a70eca78d7ca2bb8
CVE ID: CVE-2025-21772 State: PUBLISHED Published: 2025-02-27T02:18:19.528Z Last Updated: 2025-11-03T19:37:27.124Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termi
l out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a3e77da9f843e4ab93917d30c314f0283e28c124 - https://git.kernel.org/stable/c/213ba5bd81b7e97ac6e6190b8f3bc6ba76123625 - https://git.kernel.org/stable/c/40a35d14f3c0dc72b689061ec72fc9b193f37d1f - https://git.kernel.org/stable/c/27a39d006f85e869be68c1d5d2ce05e5d6445bf5 - https://git.kernel.org/stable/c/92527100be38ede924768f4277450dfe8a40e16b - https://git.kernel.org/stable/c/6578717ebca91678131d2b1f4ba4258e60536
table/c/92527100be38ede924768f4277450dfe8a40e16b - https://git.kernel.org/stable/c/6578717ebca91678131d2b1f4ba4258e60536e9f - https://git.kernel.org/stable/c/7fa9706722882f634090bfc9af642bf9ed719e27 - https://git.kernel.org/stable/c/80e648042e512d5a767da251d44132553fe04ae0
CVE ID: CVE-2025-21773 State: PUBLISHED Published: 2025-02-27T02:18:20.013Z Last Updated: 2025-10-01T19:36:40.601Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: fix potential NULL pointer dereference on udev->serial The driver assumed that es58x_dev->udev->serial could never be NULL. While this is true on commercially available devices, an attacker could spoof the device identity providing a NULL USB serial number. That would trigger a NULL pointer dereference. Add a check on es58x_dev->udev->serial before accessing it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/sta
>serial before accessing it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1590667a60753ee5a54871f2840ceefd4a7831fa - https://git.kernel.org/stable/c/722e8e1219c8b6ac2865011fe339315d6a8d0721 - https://git.kernel.org/stable/c/5059ea98d7bc133903d3e47ab36df6ed11d0c95f - https://git.kernel.org/stable/c/a1ad2109ce41c9e3912dadd07ad8a9c640064ffb
CVE ID: CVE-2025-21774 State: PUBLISHED Published: 2025-02-27T02:18:20.526Z Last Updated: 2025-10-01T19:36:40.467Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocated Fix NULL pointer check in rkcanfd_handle_rx_fifo_overflow_int() to bail out if skb cannot be allocated. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/118fb35681bd2c0d2afa22f7be0ef94bb4d06849 - https://git.kernel.org/stable/c/946750e7865df2e70045071051abf768785dd570 - https://git.kernel.org/stable/c/f7f0adfe64de08803990dc4cbecd2849
org/stable/c/946750e7865df2e70045071051abf768785dd570 - https://git.kernel.org/stable/c/f7f0adfe64de08803990dc4cbecd2849c04e314a
CVE ID: CVE-2025-21775 State: PUBLISHED Published: 2025-02-27T02:18:21.019Z Last Updated: 2025-11-03T19:37:28.523Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: ctucanfd: handle skb allocation failure If skb allocation fails, the pointer to struct can_frame is NULL. This is actually handled everywhere inside ctucan_err_interrupt() except for the only place. Add the missed NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/84b9ac59978a6a4e0812d1c938fad9730
P Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/84b9ac59978a6a4e0812d1c938fad97306272cef - https://git.kernel.org/stable/c/e505b83b9ee6aa0ae2f4395f573a66579ae403fb - https://git.kernel.org/stable/c/b0e592dd46a0a952b41c3bf6c963afdd6a42b526 - https://git.kernel.org/stable/c/e7e2e2318b1f085044126ba553a4e619842fc36d - https://git.kernel.org/stable/c/9bd24927e3eeb85642c7baa3b28be8bea6c2a078
CVE ID: CVE-2025-21776 State: PUBLISHED Published: 2025-02-27T02:18:21.503Z Last Updated: 2025-11-03T19:37:31.434Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workque
rker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuratio
for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/49f077106fa07919a6a6dda99bb490dd1d1a8218 - https://git.kernel.org/stable/c/d343f
nces: - https://git.kernel.org/stable/c/49f077106fa07919a6a6dda99bb490dd1d1a8218 - https://git.kernel.org/stable/c/d343fe0fad5c1d689775f2dda24a85ce98e29566 - https://git.kernel.org/stable/c/d3a67adb365cdfdac4620daf38a82e57ca45806c - https://git.kernel.org/stable/c/c3720b04df84b5459050ae4e03ec7d545652f897 - https://git.kernel.org/stable/c/e905a0fca7bff0855d312c16f71e60e1773b393e - https://git.kernel.org/stable/c/62d8f4c5454dd39aded4f343720d1c5a1803cfef - https://git.kernel.org/stable/c/5b9778e1fe715700993ce436c152dc3b7df0b490 - https://git.kernel.org/stable/c/2240fed37afbcdb5e8b627bc7ad986891100e05d
CVE ID: CVE-2025-21777 State: PUBLISHED Published: 2025-02-27T02:18:22.008Z Last Updated: 2025-05-04T07:20:57.840Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Validate the persistent meta data subbuf array The meta data for a mapped ring buffer contains an array of indexes of all the subbuffers. The first entry is the reader page, and the rest of the entries lay out the order of the subbuffers in how the ring buffer link list is to be created. The validator currently makes sure that all the entries are within the range of 0 and nr_subbufs. But it does not check if there are any duplicates. While working on the r
ries are within the range of 0 and nr_subbufs. But it does not check if there are any duplicates. While working on the ring buffer, I corrupted this array, where I added duplicates. The validator did not catch it and created the ring buffer link list on top of it. Luckily, the corruption was only that the reader page was also in the writer path and only presented corrupted data but did not crash the kernel. But if there were duplicates in the writer side, then it could corrupt the ring buffer link list and cause a crash. Create a bitmask array with the size of the number of subbuffers. Then clear it. When walking through the subbuf array checking to see if the entries are within the range, t
subbuffers. Then clear it. When walking through the subbuf array checking to see if the entries are within the range, test if its bit is already set in the subbuf_mask. If it is, then there is duplicates and fail the validation. If not, set the corresponding bit and continue. References: - https://git.kernel.org/stable/c/3ec743d558f111d8999aea24577ba66c65ee2eeb - https://git.kernel.org/stable/c/0d547a6f5e8fad26ebc12f501d7d19fccdbad6bf - https://git.kernel.org/stable/c/f5b95f1fa2ef3a03f49eeec658ba97e721412b32
CVE ID: CVE-2025-21778 State: PUBLISHED Published: 2025-02-27T02:18:22.506Z Last Updated: 2025-05-04T07:20:58.909Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Do not allow mmap() of persistent ring buffer When trying to mmap a trace instance buffer that is attached to reserve_mem, it would crash: BUG: unable to handle page fault for address: ffffe97bd00025c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 2862f3067 P4D 2862f3067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233 Hardw
PREEMPT_RT SMP PTI CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:validate_page_before_insert+0x5/0xb0 Code: e2 01 89 d0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 <48> 8b 46 08 a8 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89 RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246 RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29 RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08 RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004 R10:
25c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08 RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000 R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000 FS: 00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0 Call Trace: <TASK> ? __die_body.cold+0x19/0x1f ? __die+0x2e/0x40 ? page_fault_oops+0x157/0x2b0 ? search_module_extables+0x53/0x80 ? validate_page_before_insert+0x5/0xb0 ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70 ? __bad_area_nosemaphore+0x16e/0x1b0 ? bad_area_n
age_before_insert+0x5/0xb0 ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70 ? __bad_area_nosemaphore+0x16e/0x1b0 ? bad_area_nosemaphore+0x16/0x20 ? do_kern_addr_fault+0x77/0x90 ? exc_page_fault+0x22b/0x230 ? asm_exc_page_fault+0x2b/0x30 ? validate_page_before_insert+0x5/0xb0 ? vm_insert_pages+0x151/0x400 __rb_map_vma+0x21f/0x3f0 ring_buffer_map+0x21b/0x2f0 tracing_buffers_mmap+0x70/0xd0 __mmap_region+0x6f0/0xbd0 mmap_region+0x7f/0x130 do_mmap+0x475/0x610 vm_mmap_pgoff+0xf2/0x1d0 ksys_mmap_pgoff+0x166/0x200 __x64_sys_mmap+0x37/0x50 x64_sys_call+0x1670/0x1d70 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The reason was that the code that maps the ring buffer pages to user space
1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The reason was that the code that maps the ring buffer pages to user space has: page = virt_to_page((void *)cpu_buffer->subbuf_ids[s]); And uses that in: vm_insert_pages(vma, vma->vm_start, pages, &nr_pages); But virt_to_page() does not work with vmap()'d memory which is what the persistent ring buffer has. It is rather trivial to allow this, but for now just disable mmap() of instances that have their ring buffer from the reserve_mem option. If an mmap() is performed on a persistent buffer it will return -ENODEV just like it would if the .mmap field wasn't defined in the file_operations structure. References: - https://git.kernel.org/stable/c/e8d
ld if the .mmap field wasn't defined in the file_operations structure. References: - https://git.kernel.org/stable/c/e8dff5f73912513fc9b52ab992d861517c9a9975 - https://git.kernel.org/stable/c/cf5aa560e5c7628b57c928741d7e6a9a0f6f0e67 - https://git.kernel.org/stable/c/129fe718819cc5e24ea2f489db9ccd4371f0c6f6
CVE ID: CVE-2025-21779 State: PUBLISHED Published: 2025-02-27T02:18:23.001Z Last Updated: 2025-11-03T20:59:24.679Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the
CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can'
entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/61224533f2b61e252b03e214195d27d64b22989a - https://git.kernel.org/stable/c/45fa526b0f5a34492ed0536c3cdf88b78380e4de - https://git.kernel.org/stable/c/5393cf22312418262679eaadb130d608c75fe690 - https://git.kernel.org/stable/c/874ff13c73c45ecb38cb82191e8c1d523f0dc81b - https://git.kernel.org/stable/c/aca8be4403fb90db7adaf63830e27ebe787a76e8 - https://gi
73c45ecb38cb82191e8c1d523f0dc81b - https://git.kernel.org/stable/c/aca8be4403fb90db7adaf63830e27ebe787a76e8 - https://git.kernel.org/stable/c/ca29f58ca374c40a0e69c5306fc5c940a0069074 - https://git.kernel.org/stable/c/a8de7f100bb5989d9c3627d3a223ee1c863f3b69