{
"Source": "CVE FEED",
"Title": "CVE-2025-1562 - WooCommerce FunnelKit Plugin Unauthenticated Remote Code Execution",
"Content": "CVE ID : CVE-2025-1562
Published : June 18, 2025, 8:15 a.m. | 14 minutes ago
Description : The Recover WooCommerce Cart Abandonment, Newsletter, Email Marketing, Marketing Automation By FunnelKit plugin for WordPress is vulnerable to unauthorized arbitrary plugin installation due to a missing capability check on the install_or_activate_addon_plugins() function and a weak nonce hash in all versions up to, and including, 3.5.3. This makes it possible for unauthenticated attackers to install arbitrary plugins on the site that can be leveraged to further infect a vulnerable site.
Severity: 9.8 | CRITICAL
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-4955 - Tarteaucitron.io WordPress Stored Cross-site Scripting Vulnerability",
"Content": "CVE ID : CVE-2025-4955
Published : June 18, 2025, 6:15 a.m. | 2 hours, 14 minutes ago
Description : The tarteaucitron.io WordPress plugin before 1.9.5 uses query parameters from YouTube oEmbed URLs without sanitizing these parameters correctly, which could allow users with the contributor role and above to perform Stored Cross-site Scripting attacks.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-6086 - "CSV Me Plugin for WordPress File Upload Vulnerability"",
"Content": "CVE ID : CVE-2025-6086
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
Description : The CSV Me plugin for WordPress is vulnerable to arbitrary file uploads due to insufficient file type validation in the 'csv_me_options_page' function in all versions up to, and including, 2.0. This makes it possible for authenticated attackers, with Administrator-level access and above, to upload arbitrary files on the affected site's server which may make remote code execution possible.
Severity: 7.2 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-5237 - WordPress Target Video Easy Publish Stored Cross-Site Scripting",
"Content": "CVE ID : CVE-2025-5237
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
Description : The Target Video Easy Publish plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘width’ parameter in all versions up to, and including, 3.8.5 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
Severity: 6.4 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38076 - Linux Kernel alloc_tag Use-After-Free Vulnerability",
"Content": "CVE ID : CVE-2025-38076
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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 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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38077 - Dell WMI Sysman Buffer Overflow",
"Content": "CVE ID : CVE-2025-38077
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38078 - ALSA Kernel Use-After-Free",
"Content": "CVE ID : CVE-2025-38078
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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 lock, so that it won't be changed during the
operation.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38079 - Linux Kernel Double Free in algif_hash Crypto Extension",
"Content": "CVE ID : CVE-2025-38079
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38080 - AMD Display Array Buffer Overflow Vulnerability",
"Content": "CVE ID : CVE-2025-38080
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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 with current code, therefore 100 is sufficient.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38081 - Rockchip SPI Out-of-Bounds Access Vulnerability",
"Content": "CVE ID : CVE-2025-38081
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38082 - Linux Kernel gpio Virtuser Out-of-Bound Write Vulnerability",
"Content": "CVE ID : CVE-2025-38082
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38070 - Linux Kernel ASoC SMA1307 NULL Pointer Dereference Vulnerability",
"Content": "CVE ID : CVE-2025-38070
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38071 - Linux Kernel Memory Allocation Crash Vulnerability",
"Content": "CVE ID : CVE-2025-38071
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38073 - Linux kernel Block Device Large Sector Size Set Blocksize Race Condition",
"Content": "CVE ID : CVE-2025-38073
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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 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 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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38074 - QEMU vhost-scsi Invalid Memory Use Vulnerability",
"Content": "CVE ID : CVE-2025-38074
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38075 - "Linux SCSI Target Iscsi Null Pointer Dereference Vulnerability"",
"Content": "CVE ID : CVE-2025-38075
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38069 - Linux Kernel PCI Endpoint Double Free Vulnerability",
"Content": "CVE ID : CVE-2025-38069
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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]
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38072 - "CXL Memory Device Identify Error Division by Zero in Linux Kernel"",
"Content": "CVE ID : CVE-2025-38072
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38063 - XFS, Linux Kernel, Data Corruption Vulnerability",
"Content": "CVE ID : CVE-2025-38063
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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 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_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() 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().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38062 - Linux Kernel VFIO IOMMU MSI Cookie UAF",
"Content": "CVE ID : CVE-2025-38062
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2025-38064 - QEMU Virtio IOMMU Device Reset Vulnerability",
"Content": "CVE ID : CVE-2025-38064
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...",
"Detection Date": "18 Jun 2025",
"Type": "Vulnerability"
}
🔹 t.me/cvedetector 🔹