deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38056
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Intel: hda: Fix UAF when reloading module

hda_generic_machine_select() appends -idisp to the tplg filename by
allocating a new string with devm_kasprintf(), then stores the string
right back into the global variable snd_soc_acpi_intel_hda_machines.
When the module is unloaded, this memory is freed, resulting in a global
variable pointing to freed memory.  Reloading the module then triggers
a use-after-free:

BUG: KFENCE: use-after-free read in string+0x48/0xe0

Use-after-free read at 0x[PII_REDACTED]7e0109 (in kfence-#99):
 string+0x48/0xe0
 vsnprintf+0x329/0x6e0
 devm_kvasprintf+0x54/0xb0
 devm_kasprintf+0x58/0x80
 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]
 sof_probe_work+0x7f/0x600 [snd_sof]
 process_one_work+0x17b/0x330
 worker_thread+0x2ce/0x3f0
 kthread+0xcf/0x100
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30

kfence-#99: 0x[PII_REDACTED]8a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64

allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago):
 devm_kmalloc+0x52/0x120
 devm_kvasprintf+0x66/0xb0
 devm_kasprintf+0x58/0x80
 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]
 sof_probe_work+0x7f/0x600 [snd_sof]
 process_one_work+0x17b/0x330
 worker_thread+0x2ce/0x3f0
 kthread+0xcf/0x100
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30

freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago):
 release_nodes+0x43/0xb0
 devres_release_all+0x90/0xf0
 device_unbind_cleanup+0xe/0x70
 device_release_driver_internal+0x1c1/0x200
 driver_detach+0x48/0x90
 bus_remove_driver+0x6d/0xf0
 pci_unregister_driver+0x42/0xb0
 __do_sys_delete_module+0x1d1/0x310
 do_syscall_64+0x82/0x190
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Fix it by copying the match array with devm_kmemdup_array() before we
modify it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2b49e68360eb6a1c03dc1642a51f7d9f6784c034; https://git.kernel.org/stable/c/7dd7f39fce0022b386ef1ea5ffef92ecc7dfc6af; https://git.kernel.org/stable/c/f9670b2e81e8a3cbf2e1e757190dd0b920a9d43f
CVE: CVE-2025-38057
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

espintcp: fix skb leaks

A few error paths are missing a kfree_skb.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/05db2b850a2b8b17f3d1799f563ea1d550e05ed5; https://git.kernel.org/stable/c/28756f22de48d25256ed89234b66b9037a3f0157; https://git.kernel.org/stable/c/63c1f19a3be3169e51a5812d22a6d0c879414076
CVE: CVE-2025-38058
Published: 2025-06-18
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 one done before
taking that makes no sense - it's nowhere near common enough to bother
with.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/250cf3693060a5f803c5f1ddc082bb06b16112a9; https://git.kernel.org/stable/c/628fb00195ce21a90cf9e4e3d105cd9e58f77b40; https://git.kernel.org/stable/c/8cafd7266fa02e0863bacbf872fe635c0b9725eb
CVE: CVE-2025-38059
Published: 2025-06-18
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: [PII_REDACTED]
  #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), 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 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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/50d0de59f66cbe6d597481e099bf1c70fd07e0a9; https://git.kernel.org/stable/c/6e9770de024964b1017f99ee94f71967bd6edaeb; https://git.kernel.org/stable/c/d35bed14b0bc95c6845863a3744ecd10b888c830
CVE: CVE-2025-38061
Published: 2025-06-18
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).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/128cdb617a87767c29be43e[PII_REDACTED]fce41df; https://git.kernel.org/stable/c/425e64440ad0a2f03bdaf04be0ae53dededbaa77; https://git.kernel.org/stable/c/5bfa81539e22af4c40ae5d43d[PII_REDACTED]383a6
CVE: CVE-2025-38062
Published: 2025-06-18
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 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, 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, 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1f7df3a691740a7736bbc99dc4ed536120eb4746; https://git.kernel.org/stable/c/53f42776e435f63e5f8e61955e4c205dbfeaf524; https://git.kernel.org/stable/c/856152eb91e67858a09e30a7149a1f29b04b7384
CVE: CVE-2025-38063
Published: 2025-06-18
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 [ffff800084a2f820] __schedule at ffff800040bfa0c4
     #2 [ffff800084a2f880] schedule at ffff800040bfa4b4
     #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4
     #4 [ffff800084a2f8c0] rq_qos_wait at ffff[PII_REDACTED]bc
     #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0
     #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff[PII_REDACTED]54
     #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38
     #8 [ffff800084a2fa60] generic_make_request at ffff[PII_REDACTED]38
     #9 [ffff800084a2fae0] submit_bio at ffff[PII_REDACTED]b4
    #10 [ffff800084a2fb50] xlog_write_iclog at ffff[PII_REDACTED]34 [xfs]
    #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]
    #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]
    #13 [ffff800084a2fc10] xlog_write at ffff[PII_REDACTED]3c [xfs]
    #14 [ffff800084a2fcd0] xlog_cil_push at ffff[PII_REDACTED]dc [xfs]
    #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]
    #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08
    #17 [ffff800084a2fe00] worker_thread at ffff[PII_REDACTED]cc
    #18 [ffff800084a2fe70] kthread at ffff800040118de4

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().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2858cda9a8d95e6deee7e3b0a26adde696a9a4f5; https://git.kernel.org/stable/c/52aa28f7b1708d76e315d78b5ed397932a1a97c3; https://git.kernel.org/stable/c/88f7f56d16f568f19e1a695af34a7f4a6ce537a6
CVE: CVE-2025-38064
Published: 2025-06-18
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 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/8bd2fa086a04886798b505f28db[PII_REDACTED]203; https://git.kernel.org/stable/c/aee42f3d57bfa37b2716df4584edeecf63b9df4c
CVE: CVE-2025-38065
Published: 2025-06-18
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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/062e8093592fb866b8e016641a8b27feb6ac509d; https://git.kernel.org/stable/c/121f0335d91e46369bf55b5da4167d82b099a166; https://git.kernel.org/stable/c/15602508ad2f923e228b9521960b4addcd27d9c4
CVE: CVE-2025-38066
Published: 2025-06-18
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 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 | 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 /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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/00586b78eeb7c626a14ca13453a1631f88a7cf36; https://git.kernel.org/stable/c/025c8f477625eb39006ded650e7d027bcfb20e79; https://git.kernel.org/stable/c/3986ef4a9b6a0d9c28bc325d8713beba5e67586f
CVE: CVE-2025-38067
Published: 2025-06-18
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 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2df285dab00fa03a3ef939b6cb0d0d0aeb0791db; https://git.kernel.org/stable/c/3e4028ef31b69286c9d4878cee0330235f53f218; https://git.kernel.org/stable/c/48900d839a3454050fd5822e34be8d54c4ec9b86
CVE: CVE-2025-38068
Published: 2025-06-18
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.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0acdc4d6e679ba31d01e3e7e2e4124b76d6d8e2a; https://git.kernel.org/stable/c/167373d77c70c2b558aae3e327b115249bb2652c; https://git.kernel.org/stable/c/4b173bb2c4665c23f8fcf5241c7b06dfa6b5b111
CVE: CVE-2025-38069
Published: 2025-06-18
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 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]
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/8b83893d1f6c6061a7d58169ecdf9d5ee9f306ee; https://git.kernel.org/stable/c/934e9d137d937706004c325fa1474f9e3f1ba10a; https://git.kernel.org/stable/c/fe2329eff5bee461ebcafadb6ca1df0cbf5945fd
CVE: CVE-2025-38070
Published: 2025-06-18
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
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ec6bd16705fe21d6429d6b8f7981eae2142bba8; https://git.kernel.org/stable/c/f8434b8ba437d3f6cbcd9ffe8405bd16ed28fc5c
CVE: CVE-2025-38071
Published: 2025-06-18
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 without the weird reserve
allocation.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/631ca8909fd5c62b9fda9edda93924311a78a9c4; https://git.kernel.org/stable/c/8c18c904d301ffeb33b071eadc55cd6131e1e9be; https://git.kernel.org/stable/c/bffd5f2815c5234d609725cd0dc2f4bc5de2fc67
CVE: CVE-2025-38072
Published: 2025-06-18
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 (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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/1d1e1efad1cf049e888bf175a5c6be85d792620c; https://git.kernel.org/stable/c/2bd4a938d2eda96ab7288b8fa5aae84a1de8c4ca; https://git.kernel.org/stable/c/396c46d3f59a18ebcc500640e749f16e197d472b
CVE: CVE-2025-38073
Published: 2025-06-18
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-38074
Published: 2025-06-18
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 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/59614c5acf6688f7af3c245d359082c0e9e53117; https://git.kernel.org/stable/c/80cf68489681c165ded460930e391b1eb37b5f6f; https://git.kernel.org/stable/c/8312a1ccff1566f375191a89b9ba71b6eb48a8cd
CVE: CVE-2025-38075
Published: 2025-06-18
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+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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/019ca2804f3fb49a7f8e56ea6aeaa1ff32724c27; https://git.kernel.org/stable/c/2c5081439c7ab8da08427befe427f0d732ebc9f9; https://git.kernel.org/stable/c/3e6429e[PII_REDACTED]240a2c0c0b3ee99ea9b0d9c