Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-39691 State: PUBLISHED Published: 2025-09-05T17:20:57.247Z Last Updated: 2025-11-03T17:42:24.033Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/buffer: fix use-after-free when call bh_read() helper There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0
Q> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_re
p_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer wait_on_buffer(bh);--> return will return to caller put_bh --> trigger stack-out-of-bounds In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun. If the bh is not allo
equently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun. If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/70a09115da586bf662c3bae9c0c4a1b99251fad9 - https://git.kernel.org/stable/c/3169edb8945c295cf89120fc6b2c35cfe3ad4c9e - https://git.kernel.org/stable/c/03b40bf5d0389ca23ae6857ee25789f0e0b47ce8 - https://git.kernel.org/stable/c/c58c6b532b7b69537cf
//git.kernel.org/stable/c/03b40bf5d0389ca23ae6857ee25789f0e0b47ce8 - https://git.kernel.org/stable/c/c58c6b532b7b69537cfd9ef701c7e37cdcf79dc4 - https://git.kernel.org/stable/c/c5aa6ba1127307ab5dc3773eaf40d73a3423841f - https://git.kernel.org/stable/c/042cf48ecf67f72c8b3846c7fac678f472712ff3 - https://git.kernel.org/stable/c/90b5193edb323fefbee0e4e5bc39ed89dcc37719 - https://git.kernel.org/stable/c/7375f22495e7cd1c5b3b5af9dcc4f6dffe34ce49
CVE ID: CVE-2025-39692 State: PUBLISHED Published: 2025-09-05T17:20:58.349Z Last Updated: 2025-11-03T17:42:24.966Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy() We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()! Otherwise already existing connections try to use smb_direct_wq as a NULL pointer. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/524e90e58a267dad11e23351d9e4b1f941490976 - https://git.kernel.org/stable/c/212eb86f75b4d7b82f3d94aed95ba61103bccb93 - https://git.kernel.org/stabl
e4b1f941490976 - https://git.kernel.org/stable/c/212eb86f75b4d7b82f3d94aed95ba61103bccb93 - https://git.kernel.org/stable/c/003e6a3150299f681f34cb189aa068018cef6a45 - https://git.kernel.org/stable/c/e41e33400516702427603f8fbbec43c91ede09c0 - https://git.kernel.org/stable/c/bac7b996d42e458a94578f4227795a0d4deef6fa
CVE ID: CVE-2025-39693 State: PUBLISHED Published: 2025-09-05T17:20:59.287Z Last Updated: 2025-11-03T17:42:25.934Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid a NULL pointer dereference [WHY] Although unlikely drm_atomic_get_new_connector_state() or drm_atomic_get_old_connector_state() can return NULL. [HOW] Check returns before dereference. (cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9c92d12b5cb9d9d88c12ae71794d3a7382fcdec0 - https://git.kernel.org/stable/c/6f860abff89417c0354b6ee5
.kernel.org/stable/c/9c92d12b5cb9d9d88c12ae71794d3a7382fcdec0 - https://git.kernel.org/stable/c/6f860abff89417c0354b6ee5bbca188a233c5762 - https://git.kernel.org/stable/c/36a6b43573d152736eaf2557fe60580dd73e9350 - https://git.kernel.org/stable/c/f653dd30839eb4f573a7539e90b8a58ff9bedf2f - https://git.kernel.org/stable/c/0c1a486cbe6f9cb194e3c4a8ade4af2a642ba165 - https://git.kernel.org/stable/c/07b93a5704b0b72002f0c4bd1076214af67dc661
CVE ID: CVE-2025-39694 State: PUBLISHED Published: 2025-09-05T17:21:00.361Z Last Updated: 2025-11-03T17:42:26.884Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix SCCB present check Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation. If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping. F
NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping. Fix this by introducing a function that handles the NULL case before address translation. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/aa5073ac1a2a274812f3b04c278992e68ff67cc7 - https://git.kernel.org/stable/c/86c2825791c3836a8f77a954b9c5ebe6fab410c5 - https://git.kernel.org/stable/c/61605c847599fbfdfafe638607841c7d73719081 - https://git.kernel.org/stable/c/bf83ae3537359af088d6577812ed93113dfbcb7b - https://git.kernel.org/stable/c/430fa71027b6ac9bb0ce5532b8d0676777d4219a
CVE ID: CVE-2025-39695 State: PUBLISHED Published: 2025-09-05T17:21:01.198Z Last Updated: 2025-09-29T05:57:35.112Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Flush delayed SKBs while releasing RXE resources When skb packets are sent out, these skb packets still depends on the rxe resources, for example, QP, sk, when these packets are destroyed. If these rxe resources are released when the skb packets are destroyed, the call traces will appear. To avoid skb packets hang too long time in some network devices, a timestamp is added when these skb packets are created. If these skb packets hang too long time in network
rk devices, a timestamp is added when these skb packets are created. If these skb packets hang too long time in network devices, these network devices can free these skb packets to release rxe resources. References: - https://git.kernel.org/stable/c/732d4bd7b78a2752ad43cc39287ef41893c5eee2 - https://git.kernel.org/stable/c/8ead139a8edef485cc36d3a792e2ae5dd538339a - https://git.kernel.org/stable/c/3c3e9a9f2972b364e8c2cfbfdeb23c6d6be4f87f
CVE ID: CVE-2025-39696 State: PUBLISHED Published: 2025-09-05T17:21:02.068Z Last Updated: 2025-09-29T05:57:36.367Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv During the conversion to unify the calibration data management, the reference to tasdevice_priv was wrongly set to h->hda_priv instead of h->priv. This resulted in memory corruption and crashes eventually. Unfortunately it's a void pointer, hence the compiler couldn't know that it's wrong. References: - https://git.kernel.org/stable/c/2812815aa79637d39d4398ecd7e58f65d1c79231 - https://git.kernel.org/stable/c/3f4
rences: - https://git.kernel.org/stable/c/2812815aa79637d39d4398ecd7e58f65d1c79231 - https://git.kernel.org/stable/c/3f4422e7c9436abf81a00270be7e4d6d3760ec0e
CVE ID: CVE-2025-39697 State: PUBLISHED Published: 2025-09-05T17:21:03.178Z Last Updated: 2025-11-03T17:42:28.746Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(),
he page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0ff42a32784e0f2cb46a46da8e9f473538c13e1b - https://git.kernel.org/stable/c/f230d40147cc37eb3aef4d50e2e2c06ea73d9a77 - https://git.kernel.org/stable/c/c32e3c71aaa1c1ba05da88605e2ddd493c58794f - https://git.kernel.org/stable/c/181feb41f0b268e6288bf9a7b984624d7fe2031d - https://git.kernel.org/stable/c/92278ae36935a54e65fef9f8ea8efe7e80481ace - https://git.kernel.org/stable/c/202a3432d21ac060629a760fff3b0a3
.org/stable/c/92278ae36935a54e65fef9f8ea8efe7e80481ace - https://git.kernel.org/stable/c/202a3432d21ac060629a760fff3b0a39859da3ea - https://git.kernel.org/stable/c/76d2e3890fb169168c73f2e4f8375c7cc24a765e
CVE ID: CVE-2025-39698 State: PUBLISHED Published: 2025-09-05T17:21:04.360Z Last Updated: 2025-10-17T12:15:46.358Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring/futex: ensure io_futex_wait() cleans up properly on failure The io_futex_data is allocated upfront and assigned to the io_kiocb async_data field, but the request isn't marked with REQ_F_ASYNC_DATA at that point. Those two should always go together, as the flag tells io_uring whether the field is valid or not. Additionally, on failure cleanup, the futex handler frees the data but does not clear ->async_data. Clear the data and the flag in the error path as well
the futex handler frees the data but does not clear ->async_data. Clear the data and the flag in the error path as well. Thanks to Trend Micro Zero Day Initiative and particularly ReDress for reporting this. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d9f93172820a53ab42c4b0e5e65291f4f9d00ad2 - https://git.kernel.org/stable/c/d34c04152df517c59979b4bf2a47f491e06d3256 - https://git.kernel.org/stable/c/508c1314b342b78591f51c4b5dadee31a88335df - https://www.zerodayinitiative.com/advisories/ZDI-25-915/
CVE ID: CVE-2025-39699 State: PUBLISHED Published: 2025-09-05T17:21:05.379Z Last Updated: 2025-09-29T05:57:40.204Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/riscv: prevent NULL deref in iova_to_phys The riscv_iommu_pte_fetch() function returns either NULL for unmapped/never-mapped iova, or a valid leaf pte pointer that requires no further validation. riscv_iommu_iova_to_phys() failed to handle NULL returns. Prevent null pointer dereference in riscv_iommu_iova_to_phys(), and remove the pte validation. References: - https://git.kernel.org/stable/c/220c491490255b656672bb572b18460cd9155926 - https://git.kernel.org/stable
. References: - https://git.kernel.org/stable/c/220c491490255b656672bb572b18460cd9155926 - https://git.kernel.org/stable/c/99d4d1a070870aa08163af8ce0522992b7f35d8c
CVE ID: CVE-2025-39700 State: PUBLISHED Published: 2025-09-05T17:21:06.479Z Last Updated: 2025-09-29T05:57:41.441Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: ignore migration request to invalid nodes damon_migrate_pages() tries migration even if the target node is invalid. If users mistakenly make such invalid requests via DAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen. [ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48 [ 7831.884160] #PF: supervisor read access in kernel mode [ 7831.884681] #PF: error_code(0x0000) - not-present page [ 7831.885203] PGD 0 P4D
upervisor read access in kernel mode [ 7831.884681] #PF: error_code(0x0000) - not-present page [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137) [...] [ 7831.895953] Call Trace: [ 7831.896195] <TASK> [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [ 7831.896787] migrate_pages_
95] <TASK> [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851) [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.897735] migrate_pages (mm/migrate.c:2078) [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405) [...] Add a target node validity check in damon_migrate_pages(). The validity check is stolen from that of do_pages_move(), which is being used for the move_pages() system call. References: - https:
check is stolen from that of do_pages_move(), which is being used for the move_pages() system call. References: - https://git.kernel.org/stable/c/7c303fa1f311aadc17fa82b7bbf776412adf45de - https://git.kernel.org/stable/c/9d0c2d15aff96746f99a7c97221bb8ce5b62db19 - https://git.kernel.org/stable/c/7e6c3130690a01076efdf45aa02ba5d5c16849a0
CVE ID: CVE-2025-39701 State: PUBLISHED Published: 2025-09-05T17:21:07.580Z Last Updated: 2025-11-03T17:42:29.730Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPI: pfr_update: Fix the driver update version check The security-version-number check should be used rather than the runtime version check for driver updates. Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one. [ rjw: Changelog edits ] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/79300ff532bccbbf654992c7c0863b49a6c3973c - https://git.kernel.org/st
iner: References: - https://git.kernel.org/stable/c/79300ff532bccbbf654992c7c0863b49a6c3973c - https://git.kernel.org/stable/c/cf0a88124e357bffda487cbf3cb612bb97eb97e4 - https://git.kernel.org/stable/c/b00219888c11519ef75d988fa8a780da68ff568e - https://git.kernel.org/stable/c/908094681f645d3a78e18ef90561a97029e2df7b - https://git.kernel.org/stable/c/8151320c747efb22d30b035af989fed0d502176e
CVE ID: CVE-2025-39702 State: PUBLISHED Published: 2025-09-05T17:21:08.674Z Last Updated: 2025-11-03T17:42:30.669Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3b348c9c8d2ca2c67559ffd0e258ae7e1107d4f0 - https://git.kernel.org/stable/c/86b6d34717fe0570afce07ee79b8eeb40341f831 - https://git.kernel.org/stable/c/3ddd55cf19ed6cc62def5e3af10c2a9df1b861c3 - https://git.kernel
afce07ee79b8eeb40341f831 - https://git.kernel.org/stable/c/3ddd55cf19ed6cc62def5e3af10c2a9df1b861c3 - https://git.kernel.org/stable/c/b3967c493799e63f648e9c7b6cb063aa2aed04e7 - https://git.kernel.org/stable/c/f7878d47560d61e3f370aca3cebb8f42a55b990a - https://git.kernel.org/stable/c/a458b2902115b26a25d67393b12ddd57d1216aaa
CVE ID: CVE-2025-39703 State: PUBLISHED Published: 2025-09-05T17:21:09.768Z Last Updated: 2025-11-03T17:42:32.610Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net, hsr: reject HSR frame if skb can't hold tag Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG): [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEAL
-------- [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0 <snip registers, remove unreliable trace> [ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763]
br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ> This issue was found by syzkaller. The panic happens in br_dev_queue_push_xmit() once it receives
90 [ 45.428196] </IRQ> This issue was found by syzkaller. The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics. The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG). Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers. Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit(). In the reproducer, this is injected via AF_
to check for enough headroom before skb_push() in br_dev_queue_push_xmit(). In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network. Further Details: In the reproducer, the following network interface chain is set up: ┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘ To trigger the events leading up to crash, repr
───┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘ To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8d9bc4a375a1ba05f7dfa0407de8e510ab9bd14d - https://git.kernel.org/stable/c/3ae272ab523dd6bdc26e879027ed79feac9dd1b3 - https://git.kernel.org/stable/c/b640188b8a6690e685939053c7efdbc7818b5f4e - https://git.kernel.org/stable/c/b117c41b00902c1a7e24347c405cb82504aeae0b - https://git.kernel.org/stable/c/acd69b597bd3f76d3b3d322b84082226c00eeaa4 - https://git.kernel.org/stable/c/61009439e4bd8d74e705ee15940760321be91d8a - https://git.kerne
d3b3d322b84082226c00eeaa4 - https://git.kernel.org/stable/c/61009439e4bd8d74e705ee15940760321be91d8a - https://git.kernel.org/stable/c/7af76e9d18a9fd6f8611b3313c86c190f9b6a5a7
CVE ID: CVE-2025-39704 State: PUBLISHED Published: 2025-09-05T17:21:10.890Z Last Updated: 2025-09-29T05:57:46.557Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Fix stack protector issue in send_ipi_data() Function kvm_io_bus_read() is called in function send_ipi_data(), buffer size of parameter *val should be at least 8 bytes. Since some emulation functions like loongarch_ipi_readl() and kvm_eiointc_read() will write the buffer *val with 8 bytes signed extension regardless parameter len. Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTOR is enabled. The bug report is shown as follows: Ker
rwise there will be buffer overflow issue when CONFIG_STACKPROTECTOR is enabled. The bug report is shown as follows: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm] CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full) Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058 fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000
105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000 0000000000000000 0000000000000000 9000000005709968 90000000058f9000 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940 900000010001f360 0000000000000000 9000000003af3734 000000004390000c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003af3734>] show_stack+0x5c/0x180 [<9000000003aed168>] dump_stack_lvl+0x6c/0x9c [<9000000003ad0ab0>] vpanic+0x108/0x2c4 [<9000000003ad0ca8>] panic+0x3c/0x40 [<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18 [<ffff8000023473f8>] send_ipi_data+0x190/0x1a0 [kvm]
8>] panic+0x3c/0x40 [<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18 [<ffff8000023473f8>] send_ipi_data+0x190/0x1a0 [kvm] [<ffff8000023313e4>] __kvm_io_bus_write+0xa4/0xe8 [kvm] [<ffff80000233147c>] kvm_io_bus_write+0x54/0x90 [kvm] [<ffff80000233f9f8>] kvm_emu_iocsr+0x180/0x310 [kvm] [<ffff80000233fe08>] kvm_handle_gspr+0x280/0x478 [kvm] [<ffff8000023443e8>] kvm_handle_exit+0xc0/0x130 [kvm] References: - https://git.kernel.org/stable/c/b5b49d341f90eed6de794b6ff34ad3dd66d34343 - https://git.kernel.org/stable/c/5c68549c81bcca70fc464e305ffeefd9af968287