Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-38058 State: PUBLISHED Published: 2025-06-18T09:33:38.022Z Last Updated: 2025-11-03T17:33:27.007Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current o
g the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/628fb00195ce21a90cf9e4e3d105cd9e58f77b40 - https://git.kernel.org/stable/c/b89eb56a378b7b2c1176787fc228d0a57172bdd5 - https://git.kernel.org/stable/c/f6d45fd92f62845cbd1eb5128fd8f0ed7d0c5a42 - https://git.kernel.org/stable/c/9b0915e72b3cf52474dcee0b24a2f99d93e604a3 - https://git.kernel.org/stable/c/d8ece4ced3b051e656c77180df2e69e19e24edc1 - https://git.kernel.org/stable/c/8cafd7266fa02e08
ps://git.kernel.org/stable/c/d8ece4ced3b051e656c77180df2e69e19e24edc1 - https://git.kernel.org/stable/c/8cafd7266fa02e0863bacbf872fe635c0b9725eb - https://git.kernel.org/stable/c/b55996939c71a3e1a38f3cdc6a8859797efc9083 - https://git.kernel.org/stable/c/250cf3693060a5f803c5f1ddc082bb06b16112a9
CVE ID: CVE-2025-38059 State: PUBLISHED Published: 2025-06-18T09:33:38.943Z Last Updated: 2025-09-03T12:59:30.306Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid NULL pointer dereference if no valid csum tree [BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace: BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
D: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: <TASK> scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find a
AUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification. Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all. This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash. [FIX] Check both extent and csum tree root before doing any tree search. References: - https://git.kernel.org/stable/c/50d0de59f66cbe6d597481e099bf1c70fd07e0a9 - https://git.kernel.org/stable/c/6e9770de024964b1017f99ee94f71967bd6edaeb - https://git.kernel.org/stable/c/d35bed14b0b
- https://git.kernel.org/stable/c/6e9770de024964b1017f99ee94f71967bd6edaeb - https://git.kernel.org/stable/c/d35bed14b0bc95c6845863a3744ecd10b888c830 - https://git.kernel.org/stable/c/f95d186255b319c48a365d47b69bd997fecb674e
CVE ID: CVE-2025-38060 State: PUBLISHED Published: 2025-06-18T09:33:39.610Z Last Updated: 2025-09-03T12:59:31.975Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: copy_verifier_state() should copy 'loop_entry' field The bpf_verifier_state.loop_entry state should be copied by copy_verifier_state(). Otherwise, .loop_entry values from unrelated states would poison env->cur_state. Additionally, env->stack should not contain any states with .loop_entry != NULL. The states in env->stack are yet to be verified, while .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should a
hile .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should always be NULL after pop_stack(). See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix. This change has some verification performance impact for selftests: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47
arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%) And significant negative impact for sc
ifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%) And significant negative impact for sched_ext: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68
yered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch ---truncated--- References: - https://git.kernel.org/stable/c/46ba5757a7a4714e7d3f68cfe118208822cb3d78 - https://git.kernel.org/stable
- References: - https://git.kernel.org/stable/c/46ba5757a7a4714e7d3f68cfe118208822cb3d78 - https://git.kernel.org/stable/c/8b4afd89fa75f738a80ca849126fd3cad77bcbf1 - https://git.kernel.org/stable/c/bbbc02b7445ebfda13e4847f4f1413c6480a85a9
CVE ID: CVE-2025-38061 State: PUBLISHED Published: 2025-06-18T09:33:40.241Z Last Updated: 2025-11-03T17:33:28.877Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix access outside of user given buffer in pktgen_thread_write() Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a3d89f1cfe1e6d4bb164db2595511fd33db21900 - https://git.kernel.org/stable/c/5bfa81539e22af4c40ae5d43d7212253462383a6 - https://git.kernel.org/stable/c/128cdb617a877
https://git.kernel.org/stable/c/5bfa81539e22af4c40ae5d43d7212253462383a6 - https://git.kernel.org/stable/c/128cdb617a87767c29be43e4431129942fce41df - https://git.kernel.org/stable/c/ef1158a6a650ecee72ab40851b1d52e04d3f9cb5 - https://git.kernel.org/stable/c/c81c2ee1c3b050ed5c4e92876590cc7a259183f6 - https://git.kernel.org/stable/c/6b1d3e9db82d01a88de1795b879df67c2116b4f4 - https://git.kernel.org/stable/c/8fef258b555c75a467a6b4b7e3a3cbc46d5f4102 - https://git.kernel.org/stable/c/425e64440ad0a2f03bdaf04be0ae53dededbaa77
CVE ID: CVE-2025-38062 State: PUBLISHED Published: 2025-06-18T09:33:41.282Z Last Updated: 2025-11-03T17:33:29.808Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie The IOMMU translation for MSI message addresses has been a 2-step process, separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address. This has an inherent lifetime problem for the pointer store
kie pointer is used to compute a translated message address. This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached. Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up. However
nging the iommu domain while VFIO was running as it does not support changing the "container" after starting up. However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()). This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs. Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus,
he cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor. The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e4d3763223c7b72ded53425207075e7453b4e3d5 - https://git.kernel.org/stable/c/ba41e4e627db51d914444aee0b93eb67f31fa330 - https://git.kernel.org/stable/c/53f42776e435f63e5f8e61955e4c205dbfeaf524 - https://git.kernel.org/stable/c/856152eb91e67858a09e30a
t.kernel.org/stable/c/53f42776e435f63e5f8e61955e4c205dbfeaf524 - https://git.kernel.org/stable/c/856152eb91e67858a09e30a7149a1f29b04b7384 - https://git.kernel.org/stable/c/1f7df3a691740a7736bbc99dc4ed536120eb4746
CVE ID: CVE-2025-38063 State: PUBLISHED Published: 2025-06-18T09:33:41.977Z Last Updated: 2025-11-03T17:33:30.748Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm: fix unconditional IO throttle caused by REQ_PREFLUSH When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush() generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, which causes the flush_bio to be throttled by wbt_wait(). An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a
fff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_
t_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4 After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlog_write_iclog()
de4 After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlog_write_iclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled. Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes wbt_should_throttle() return false to avoid wbt_wait(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/95d08924335f3b6f4ea0b92ebfe4fe0731c502d9 - https://git.kernel.org/stable/c/52aa28f7b1708d76e315d78b5ed397932a1a97c3 - https://git.kernel.org/stable/c/b55a97d1bd4083729a60d19beffe85d4c96680de - https://git.kernel.
315d78b5ed397932a1a97c3 - https://git.kernel.org/stable/c/b55a97d1bd4083729a60d19beffe85d4c96680de - https://git.kernel.org/stable/c/2858cda9a8d95e6deee7e3b0a26adde696a9a4f5 - https://git.kernel.org/stable/c/88f7f56d16f568f19e1a695af34a7f4a6ce537a6
CVE ID: CVE-2025-38064 State: PUBLISHED Published: 2025-06-18T09:33:42.931Z Last Updated: 2025-06-18T09:33:42.931Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio: break and reset virtio devices on device_shutdown() Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory accesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ... It was traced down to virtio-console. Kexec works fine if virtio-console is not in use. The issue is that virtio-console continues to write to the MMIO even aft
xec works fine if virtio-console is not in use. The issue is that virtio-console continues to write to the MMIO even after underlying virtio-pci device is reset. Additionally, Eric noticed that IOMMUs are reset before devices, if devices are not reset on shutdown they continue to poke at guest memory and get errors from the IOMMU. Some devices get wedged then. The problem can be solved by breaking all virtio devices on virtio bus shutdown, then resetting them. References: - https://git.kernel.org/stable/c/aee42f3d57bfa37b2716df4584edeecf63b9df4c - https://git.kernel.org/stable/c/8bd2fa086a04886798b505f28db4002525895203
CVE ID: CVE-2025-38065 State: PUBLISHED Published: 2025-06-18T09:33:44.048Z Last Updated: 2025-11-03T17:33:32.733Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: orangefs: Do not truncate file size 'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ceaf195ed285b77791e29016ee6344b3ded609b3 - https://git.kernel.org/stable/c/341e3a5984cf5761f3dab16029d7e9fb1641d5ff - https://git.kernel.org/stable/c/5111227d7f1f57f6804666b3abf780a23f44fc1d - https://git.kernel.or
ab16029d7e9fb1641d5ff - https://git.kernel.org/stable/c/5111227d7f1f57f6804666b3abf780a23f44fc1d - https://git.kernel.org/stable/c/15602508ad2f923e228b9521960b4addcd27d9c4 - https://git.kernel.org/stable/c/121f0335d91e46369bf55b5da4167d82b099a166 - https://git.kernel.org/stable/c/cd918ec24168fe08c6aafc077dd3b6d88364c5cf - https://git.kernel.org/stable/c/2323b806221e6268a4e17711bc72e2fc87c191a3 - https://git.kernel.org/stable/c/062e8093592fb866b8e016641a8b27feb6ac509d
CVE ID: CVE-2025-38066 State: PUBLISHED Published: 2025-06-18T09:33:44.877Z Last Updated: 2025-11-03T17:33:34.607Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm cache: prevent BUG_ON by blocking retries on failed device resumes A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object. Reproduce steps: 1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the ma
te a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata. cat <<EOF >> cmeta.xml <superblock uuid="" block_size="128" nr_cache_blocks="512" \ policy="smq" hint_width="4"> <mappings> <mapping cache_block="0" origin_block="0" dirty="false"/> </mappings> </superblock> EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. wipe the second array block of the mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hex
he mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try bringing up the cache device. The resume is expected to fail due to the broken array block. dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /
62144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache 4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings. dmsetup resume cache Kernel logs: (snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570 Fix by disallowing resume operations for devices that failed the initial attempt. Additional Analyst Notes: - CVE Program Con
y disallowing resume operations for devices that failed the initial attempt. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c614584c2a66b538f469089ac089457a34590c14 - https://git.kernel.org/stable/c/c5356a5e80442131e2714d0d26bb110590e4e568 - https://git.kernel.org/stable/c/025c8f477625eb39006ded650e7d027bcfb20e79 - https://git.kernel.org/stable/c/00586b78eeb7c626a14ca13453a1631f88a7cf36 - https://git.kernel.org/stable/c/3986ef4a9b6a0d9c28bc325d8713beba5e67586f - https://git.kernel.org/stable/c/cc80a5cc520939d0a7d071cc4ae4b3c55ef171d0 - https://git.kernel.org/stable/c/f3128e3074e8af565cc6a66fe3384a56df87f803 - https://git.kernel.org/stable/c/5
55ef171d0 - https://git.kernel.org/stable/c/f3128e3074e8af565cc6a66fe3384a56df87f803 - https://git.kernel.org/stable/c/5da692e2262b8f81993baa9592f57d12c2703dea
CVE ID: CVE-2025-38067 State: PUBLISHED Published: 2025-06-18T09:33:45.518Z Last Updated: 2025-11-03T17:33:36.482Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rseq: Fix segfault on registration when rseq_cs is non-zero The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs. The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of
tion to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs. What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/
reas on thread creation. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/48900d839a3454050fd5822e34be8d54c4ec9b86 - https://git.kernel.org/stable/c/3e4028ef31b69286c9d4878cee0330235f53f218 - https://git.kernel.org/stable/c/b2b05d0dc2f4f0646922068af435aed5763d16ba - https://git.kernel.org/stable/c/eaf112069a904b6207b4106ff083e0208232a2eb - https://git.kernel.org/stable/c/f004f58d18a2d3dc761cf973ad27b4a5997bd876 - https://git.kernel.org/stable/c/2df285dab00fa03a3ef939b6cb0d0d0aeb0791db - https://git.kernel.org/stable/c/fd881d0a085fc54354414aed990ccf05f282ba53
CVE ID: CVE-2025-38068 State: PUBLISHED Published: 2025-06-18T09:33:46.125Z Last Updated: 2025-11-03T17:33:37.495Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: lzo - Fix compression buffer overrun Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller. Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel