Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
se the safe interface in crypto/lzo. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4b173bb2c4665c23f8fcf5241c7b06dfa6b5b111 - https://git.kernel.org/stable/c/a98bd864e16f91c70b2469adf013d713d04d1d13 - https://git.kernel.org/stable/c/0acdc4d6e679ba31d01e3e7e2e4124b76d6d8e2a - https://git.kernel.org/stable/c/7caad075acb634a74911830d6386c50ea12566cd - https://git.kernel.org/stable/c/167373d77c70c2b558aae3e327b115249bb2652c - https://git.kernel.org/stable/c/cc47f07234f72cbd8e2c973cdbf2a6730660a463
CVE ID: CVE-2025-38069 State: PUBLISHED Published: 2025-06-18T09:33:46.711Z Last Updated: 2025-06-18T09:33:46.711Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous ass
when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log] References: - https://git.kernel.org/stable/c/fe2329eff5bee461ebcafadb6ca1df0cbf5945fd - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/fe2329eff5bee461ebcafadb6ca1df0cbf5945fd - https://git.kernel.org/stable/c/8b83893d1f6c6061a7d58169ecdf9d5ee9f306ee - https://git.kernel.org/stable/c/934e9d137d937706004c325fa1474f9e3f1ba10a
CVE ID: CVE-2025-38070 State: PUBLISHED Published: 2025-06-18T09:33:47.351Z Last Updated: 2025-06-19T13:11:03.569Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: sma1307: Add NULL check in sma1307_setting_loaded() All varibale allocated by kzalloc and devm_kzalloc could be NULL. Multiple pointer checks and their cleanup are added. This issue is found by our static analysis tool References: - https://git.kernel.org/stable/c/f8434b8ba437d3f6cbcd9ffe8405bd16ed28fc5c - https://git.kernel.org/stable/c/0ec6bd16705fe21d6429d6b8f7981eae2142bba8
CVE ID: CVE-2025-38071 State: PUBLISHED Published: 2025-06-18T09:33:47.975Z Last Updated: 2025-11-03T17:33:38.438Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mm: Check return value from memblock_phys_alloc_range() At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblock_phys_alloc_range() returns 0 on failure, which leads memblock_phys_free() to throw the first 4 MiB of physical memory to the wolves. At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine with
ves. At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8c18c904d301ffeb33b071eadc55cd6131e1e9be - https://git.kernel.org/stable/c/bffd5f2815c5234d609725cd0dc2f4bc5de2fc67 - https://git.kernel.org/stable/c/c6f2694c580c27dca0cf7546ee9b4bfa6b940e38 - https://git.kernel.org/stable/c/dde4800d2b0f68b945fd81d4fc2d4a10ae25f743 - https://git.kernel.org/stable/c/631ca8909fd5c62b9fda9edda93924311a78a9c4
CVE ID: CVE-2025-38072 State: PUBLISHED Published: 2025-06-18T09:33:48.666Z Last Updated: 2025-11-03T17:33:40.308Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Fix divide error in nd_label_data_init() If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (C
x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer is set to zero (nvdimm driver): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) A subsequent DIV_ROUND_UP() causes a division by zero: drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Fix this by checking the config size parameter by extending an existing check. Additional Analyst Notes: - CVE Progra
); Fix this by checking the config size parameter by extending an existing check. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2bd4a938d2eda96ab7288b8fa5aae84a1de8c4ca - https://git.kernel.org/stable/c/396c46d3f59a18ebcc500640e749f16e197d472b - https://git.kernel.org/stable/c/f49c337037df029440a8390380dd35d2cf5924d3 - https://git.kernel.org/stable/c/db1aef51b8e66a77f76b1250b914589c31a0a0ed - https://git.kernel.org/stable/c/ea3d95e05e97ea20fd6513f647393add16fce3b2 - https://git.kernel.org/stable/c/1d1e1efad1cf049e888bf175a5c6be85d792620c - https://git.kernel.org/stable/c/e14347f647ca6d76fe1509b6703e340f2d5e2716 - https://git.kernel.org/stabl
c6be85d792620c - https://git.kernel.org/stable/c/e14347f647ca6d76fe1509b6703e340f2d5e2716 - https://git.kernel.org/stable/c/ef1d3455bbc1922f94a91ed58d3d7db440652959
CVE ID: CVE-2025-38073 State: PUBLISHED Published: 2025-06-18T09:33:49.393Z Last Updated: 2025-10-23T14:32:11.157Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: fix race between set_blocksize and read paths With the new large sector size support, it's now the case that set_blocksize can change i_blksize and the folio order in a manner that conflicts with a concurrent reader and causes a kernel crash. Specifically, let's say that udev-worker calls libblkid to detect the labels on a block device. The read call can create an order-0 folio to read the first 4096 bytes from the disk. But then udev is preempted. Next, someone
d call can create an order-0 folio to read the first 4096 bytes from the disk. But then udev is preempted. Next, someone tries to mount an 8k-sectorsize filesystem from the same block device. The filesystem calls set_blksize, which sets i_blksize to 8192 and the minimum folio order to 1. Now udev resumes, still holding the order-0 folio it allocated. It then tries to schedule a read bio and do_mpage_readahead tries to create bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because the page size is 4096 but the blocksize is 8192 so no bufferheads are attached and the bh walk never sets bdev. We then submit the bio with a NULL block device and crash. Therefore, truncate the page
and the bh walk never sets bdev. We then submit the bio with a NULL block device and crash. Therefore, truncate the page cache after flushing but before updating i_blksize. However, that's not enough -- we also need to lock out file IO and page faults during the update. Take both the i_rwsem and the invalidate_lock in exclusive mode for invalidations, and in shared mode for read/write operations. I don't know if this is the correct fix, but xfs/259 found it. References: - https://git.kernel.org/stable/c/a0caf1de97e1edd7f3451f1818ea6cb970495fc5 - https://git.kernel.org/stable/c/64f505b08e0cfd8163491c8c082d4f47a88e51d4 - https://git.kernel.org/stable/c/8c5cf440a378801d313eb58be996fdc81a8878a4
e/c/64f505b08e0cfd8163491c8c082d4f47a88e51d4 - https://git.kernel.org/stable/c/8c5cf440a378801d313eb58be996fdc81a8878a4 - https://git.kernel.org/stable/c/c0e473a0d226479e8e925d5ba93f751d8df628e9
CVE ID: CVE-2025-38074 State: PUBLISHED Published: 2025-06-18T09:33:50.006Z Last Updated: 2025-11-03T17:33:42.169Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq->log_used with vq->mutex The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming
log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/80cf68489681c165ded460930e391b1eb37b5f6f - https://git.kernel.org/stable/c/8312a1ccff1566f375191a89b9ba71b6eb48a8cd - https://git.kernel.org/stable/c/59614c5acf6688f7af3c245d359082c0e9e53117 - https://git.kernel.org/stable/c/ca85c2d0db5f8309832be45858b960d933c2131c - https://git.kern
f7af3c245d359082c0e9e53117 - https://git.kernel.org/stable/c/ca85c2d0db5f8309832be45858b960d933c2131c - https://git.kernel.org/stable/c/bd8c9404e44adb9f6219c09b3409a61ab7ce3427 - https://git.kernel.org/stable/c/c0039e3afda29be469d29b3013d7f9bdee136834 - https://git.kernel.org/stable/c/f591cf9fce724e5075cc67488c43c6e39e8cbe27
CVE ID: CVE-2025-38075 State: PUBLISHED Published: 2025-06-18T09:33:50.646Z Last Updated: 2025-11-03T17:33:44.033Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix timeout on deleted connection NOPIN response timer may expire on a deleted connection and crash with such logs: Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xf
0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 That is because nopin response timer may be re-started on nopin timer expiration. Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/571ce6b6f5cbaf7d24af03cad592fc0e2a54de35 - https://git.kernel.org/stable/c/2c5081439c7ab8da08427befe427f0d732ebc9f9 - https://git.kernel
24af03cad592fc0e2a54de35 - https://git.kernel.org/stable/c/2c5081439c7ab8da08427befe427f0d732ebc9f9 - https://git.kernel.org/stable/c/019ca2804f3fb49a7f8e56ea6aeaa1ff32724c27 - https://git.kernel.org/stable/c/6815846e0c3a62116a7da9740e3a7c10edc5c7e9 - https://git.kernel.org/stable/c/fe8421e853ef289e1324fcda004751c89dd9c18a - https://git.kernel.org/stable/c/87389bff743c55b6b85282de91109391f43e0814 - https://git.kernel.org/stable/c/3e6429e3707943078240a2c0c0b3ee99ea9b0d9c - https://git.kernel.org/stable/c/7f533cc5ee4c4436cee51dc58e81dfd9c3384418
CVE ID: CVE-2025-38076 State: PUBLISHED Published: 2025-06-18T09:33:51.293Z Last Updated: 2025-06-18T09:33:51.293Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: alloc_tag: allocate percpu counters for module tags dynamically When a module gets unloaded it checks whether any of its tags are still in use and if so, we keep the memory containing module's allocation tags alive until all tags are unused. However percpu counters referenced by the tags are freed by free_module(). This will lead to UAF if the memory allocated by a module is accessed after module was unloaded. To fix this we allocate percpu counters for module allocati
allocated by a module is accessed after module was unloaded. To fix this we allocate percpu counters for module allocation tags dynamically and we keep it alive for tags which are still in use after module unloading. This also removes the requirement of a larger PERCPU_MODULE_RESERVE when memory allocation profiling is enabled because percpu memory for counters does not need to be reserved anymore. References: - https://git.kernel.org/stable/c/3cc733e6d96c938d2b82be96858a0ab900eb6fdc - https://git.kernel.org/stable/c/12ca42c237756182aad8ab04654c952765cb9061
CVE ID: CVE-2025-38077 State: PUBLISHED Published: 2025-06-18T09:33:51.986Z Last Updated: 2025-11-03T17:33:44.963Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store() If the 'buf' array received from the user contains an empty string, the 'length' variable will be zero. Accessing the 'buf' array element with index 'length - 1' will result in a buffer overflow. Add a check for an empty string. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/
sting.org) with SVACE. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fb7cde625872709b8cedad9b241e0ec3d82fa7d3 - https://git.kernel.org/stable/c/60bd13f8c4b3de2c910ae1cdbef85b9bbc9685f5 - https://git.kernel.org/stable/c/f86465626917df3b8bdd2756ec0cc9d179c5af0f - https://git.kernel.org/stable/c/8594a123cfa23d708582dc6fb36da34479ef8a5b - https://git.kernel.org/stable/c/97066373ffd55bd9af0b512ff3dd1f647620a3dc - https://git.kernel.org/stable/c/4e89a4077490f52cde652d17e32519b666abf3a6
CVE ID: CVE-2025-38078 State: PUBLISHED Published: 2025-06-18T09:33:52.644Z Last Updated: 2025-11-03T17:33:46.827Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access
performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c0e05a76fc727929524ef24a19c302e6dd40233f - https://git.kernel.org/stable/c/8170d8ec4efd0be352c14cb61f374e30fb0c2a25 - https://git.kernel.org/stable/c/10217da9644ae75cea7330f902c35fc5ba78bbbf - https://git.kernel.org/stable/c/f3e14d706ec18faf19f5a6e75060e140fea05d4a - https://git.kernel.org/stable/c/74d90875f3d43f3eff0e9861c4701418795d3455 - https://git.kernel.org/stable/c/bf85e49aaf3a3c5775ea87369ea5f159c2148db4 - https://g
5f3d43f3eff0e9861c4701418795d3455 - https://git.kernel.org/stable/c/bf85e49aaf3a3c5775ea87369ea5f159c2148db4 - https://git.kernel.org/stable/c/afa56c960fcb4db37f2e3399f28e9402e4e1f470 - https://git.kernel.org/stable/c/93a81ca0657758b607c3f4ba889ae806be9beb73
CVE ID: CVE-2025-38079 State: PUBLISHED Published: 2025-06-18T09:33:53.251Z Last Updated: 2025-11-03T17:33:48.696Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: algif_hash - fix double free in hash_accept If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5bff312b59b3f2a54ff504e4f4e47272b64f3633 - https://git.kernel.org/stable/c/bf7bba75b91539e93615f560893a599c1e1c98bf - https:
312b59b3f2a54ff504e4f4e47272b64f3633 - https://git.kernel.org/stable/c/bf7bba75b91539e93615f560893a599c1e1c98bf - https://git.kernel.org/stable/c/c3059d58f79fdfb2201249c2741514e34562b547 - https://git.kernel.org/stable/c/f0f3d09f53534ea385d55ced408f2b67059b16e4 - https://git.kernel.org/stable/c/134daaba93193df9e988524b5cd2f52d15eb1993 - https://git.kernel.org/stable/c/2f45a8d64fb4ed4830a4b3273834ecd6ca504896 - https://git.kernel.org/stable/c/0346f4b742345d1c733c977f3a7aef5a6419a967 - https://git.kernel.org/stable/c/b2df03ed4052e97126267e8c13ad4204ea6ba9b6
CVE ID: CVE-2025-38080 State: PUBLISHED Published: 2025-06-18T09:33:53.920Z Last Updated: 2025-07-11T17:21:43.246Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase block_sequence array size [Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash. [How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 w
nd on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient. References: - https://git.kernel.org/stable/c/de67e80ab48f1f23663831007a2fa3c1471a7757 - https://git.kernel.org/stable/c/e55c5704b12eeea27e212bfab8f7e51ad3e8ac1f - https://git.kernel.org/stable/c/bf1666072e7482317cf2302621766482a21a62c7 - https://git.kernel.org/stable/c/3a7810c212bcf2f722671dadf4b23ff70a7d23ee
CVE ID: CVE-2025-38081 State: PUBLISHED Published: 2025-06-18T09:33:54.564Z Last Updated: 2025-07-15T15:43:57.474Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi-rockchip: Fix register out of bounds access Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense. References: - https://git.kernel.org/stable/c/4a120221661fcecb253448d7b041a52d47f1d91f - https://git.kernel.org/stable/c/ace57bd1fb49d193edec5f6a1f255f48dd5fca90 - https://git.kernel.org/stable/c/254e04ec799c1ff8c1e2bd08a57c6a849895d6ff - https://git.kernel.org/stable/c/7a874e8b54ea21094f
://git.kernel.org/stable/c/254e04ec799c1ff8c1e2bd08a57c6a849895d6ff - https://git.kernel.org/stable/c/7a874e8b54ea21094f7fd2d428b164394c6cb316
CVE ID: CVE-2025-38082 State: PUBLISHED Published: 2025-06-18T09:35:41.902Z Last Updated: 2025-06-19T13:11:05.033Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gpio: virtuser: fix potential out-of-bound write If the caller wrote more characters, count is truncated to the max available space in "simple_write_to_buffer". Check that the input size does not exceed the buffer size. Write a zero termination afterwards. References: - https://git.kernel.org/stable/c/afe090366f470f77e140ff3407db813f57852c04 - https://git.kernel.org/stable/c/b96feaaa0fda1e3871b438143c3446954b32d3a7 - https://git.kernel.org/stable/c/7118be7c6072f4039192
/git.kernel.org/stable/c/b96feaaa0fda1e3871b438143c3446954b32d3a7 - https://git.kernel.org/stable/c/7118be7c6072f40391923543fdd1563b8d56377c
CVE ID: CVE-2025-38083 State: PUBLISHED Published: 2025-06-20T11:21:51.554Z Last Updated: 2025-11-03T17:33:50.557Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net_sched: prio: fix a race in prio_tune() Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because
derflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/53d11560e957d53ee87a0653d258038ce12361b7 - https://git.kernel.org/stable/c/4483d8b9127591c60c4eb789d6cab953bc4522a9 - https://git.kernel.org/stable/c/20f68e6a9e41693cb0e55e5b9ebbcb40983a4b8f - https://git.kernel.org/stable/c/3aaa7c01cf19d9b9bb64b88b65c3a6fd05da2eb4 - https://git.kernel.org/stable/c/46c15c9d0f65c9ba857d63f53264f4b17e8a715f - https://git.kernel.org/stable/c/e3f6745006dc9423d2b065b90f191cfa11b1b58
ble/c/46c15c9d0f65c9ba857d63f53264f4b17e8a715f - https://git.kernel.org/stable/c/e3f6745006dc9423d2b065b90f191cfa11b1b584 - https://git.kernel.org/stable/c/93f9eeb678d4c9c1abf720b3615fa8299a490845 - https://git.kernel.org/stable/c/d35acc1be3480505b5931f17e4ea9b7617fea4d3
CVE ID: CVE-2025-38084 State: PUBLISHED Published: 2025-06-28T07:44:25.379Z Last Updated: 2025-11-03T17:33:52.441Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from
o be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit
n shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e8847d18cd9fff1edbb45e963d9141273c3b539c - https://git.kernel.org/stable/c/366298f2b04d2bf1f2f2b7078405bdf9df9bd5d0 - https://git.kernel.org/stable/c/2511ac64bc1617ca716d3ba8464e481a647c1902 - https://git.kernel.org/stable/c/af6cfcd0ef