{
"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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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 🔹
"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 🔹
{
"Source": "CVE FEED",
"Title": "CVE-2025-38065 - Orangefs Size Truncation Vulnerability",
"Content": "CVE ID : CVE-2025-38065
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
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-38065 - Orangefs Size Truncation Vulnerability",
"Content": "CVE ID : CVE-2025-38065
Published : June 18, 2025, 10:15 a.m. | 23 minutes ago
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.
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-6220 - "Ultra Addons for Contact Form 7 Arbitrary File Upload Vulnerability"",
"Content": "CVE ID : CVE-2025-6220
Published : June 18, 2025, 12:15 p.m. | 27 minutes ago
Description : The Ultra Addons for Contact Form 7 plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'save_options' function in all versions up to, and including, 3.5.12. 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-6220 - "Ultra Addons for Contact Form 7 Arbitrary File Upload Vulnerability"",
"Content": "CVE ID : CVE-2025-6220
Published : June 18, 2025, 12:15 p.m. | 27 minutes ago
Description : The Ultra Addons for Contact Form 7 plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'save_options' function in all versions up to, and including, 3.5.12. 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-2022-50230 - Linux Kernel Arm64 Uxn Inconsistent Page Table Vulnerability",
"Content": "CVE ID : CVE-2022-50230
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
arm64: set UXN on swapper page tables
[ This issue was fixed upstream by accident in c3cee924bd85 ("arm64:
head: cover entire kernel image in initial ID map") as part of a
large refactoring of the arm64 boot flow. This simple fix is therefore
preferred for -stable backporting ]
On a system that implements FEAT_EPAN, read/write access to the idmap
is denied because UXN is not set on the swapper PTEs. As a result,
idmap_kpti_install_ng_mappings panics the kernel when accessing
__idmap_kpti_flag. Fix it by setting UXN on these PTEs.
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-2022-50230 - Linux Kernel Arm64 Uxn Inconsistent Page Table Vulnerability",
"Content": "CVE ID : CVE-2022-50230
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
arm64: set UXN on swapper page tables
[ This issue was fixed upstream by accident in c3cee924bd85 ("arm64:
head: cover entire kernel image in initial ID map") as part of a
large refactoring of the arm64 boot flow. This simple fix is therefore
preferred for -stable backporting ]
On a system that implements FEAT_EPAN, read/write access to the idmap
is denied because UXN is not set on the swapper PTEs. As a result,
idmap_kpti_install_ng_mappings panics the kernel when accessing
__idmap_kpti_flag. Fix it by setting UXN on these PTEs.
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-2022-50231 - Huawei Crypto Poly1305 Arm64 Out-of-Bounds Read Vulnerability",
"Content": "CVE ID : CVE-2022-50231
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
crypto: arm64/poly1305 - fix a read out-of-bound
A kasan error was reported during fuzzing:
BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
Call trace:
dump_backtrace+0x0/0x394
show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x158/0x1e4 lib/dump_stack.c:118
print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
__kasan_report+0xe0/0x140 mm/kasan/report.c:547
kasan_report+0x44/0xe0 mm/kasan/report.c:564
check_memory_region_inline mm/kasan/generic.c:187 [inline]
__asan_load4+0x94/0xd0 mm/kasan/generic.c:252
neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
crypto_shash_update crypto/shash.c:131 [inline]
shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
essiv_skcipher_setkey+0x164/0x200 [essiv]
crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
__sys_setsockopt+0x190/0x2e0 net/socket.c:2123
__do_sys_setsockopt net/socket.c:2134 [inline]
__se_sys_setsockopt net/socket.c:2131 [inline]
__arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683
This error can be reproduced by the following code compiled as ko on a
system with kasan enabled:
#include
#include
#include
#include
char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"
"\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
"\x10\x11\x12\x13\x14\x15\x16\x17"
"\x18\x19\x1a\x1b\x1c\x1d\x1e";
int init(void)
{
struct crypto_shash *tfm = NULL;
char *data = NULL, *out = NULL;
tfm = crypto_alloc_shash("poly1305", 0, 0);
data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);
out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);
memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);
kfree(data);
kfree(out);
return 0;
}
void deinit(void)
{
}
module_init(init)
module_exit(deinit)
MODULE_LICENSE("GPL");
The root cause of the bug sits in neon_poly1305_blocks. The logic
neon_poly1305_blocks() performed is that if it was called with both s[]
and r[] uninitialized, it will first try to initialize them with the
data from the first "block" that it believed to be 32 bytes in length.
First 16 bytes are used as the key and the next 16 bytes for s[]. This
would lead to the aforementioned read out-of-bound. However, after
calling poly1305_init_arch(), only 16 bytes were[...]
"Source": "CVE FEED",
"Title": "CVE-2022-50231 - Huawei Crypto Poly1305 Arm64 Out-of-Bounds Read Vulnerability",
"Content": "CVE ID : CVE-2022-50231
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
crypto: arm64/poly1305 - fix a read out-of-bound
A kasan error was reported during fuzzing:
BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
Call trace:
dump_backtrace+0x0/0x394
show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x158/0x1e4 lib/dump_stack.c:118
print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
__kasan_report+0xe0/0x140 mm/kasan/report.c:547
kasan_report+0x44/0xe0 mm/kasan/report.c:564
check_memory_region_inline mm/kasan/generic.c:187 [inline]
__asan_load4+0x94/0xd0 mm/kasan/generic.c:252
neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
crypto_shash_update crypto/shash.c:131 [inline]
shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
essiv_skcipher_setkey+0x164/0x200 [essiv]
crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
__sys_setsockopt+0x190/0x2e0 net/socket.c:2123
__do_sys_setsockopt net/socket.c:2134 [inline]
__se_sys_setsockopt net/socket.c:2131 [inline]
__arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683
This error can be reproduced by the following code compiled as ko on a
system with kasan enabled:
#include
#include
#include
#include
char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"
"\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
"\x10\x11\x12\x13\x14\x15\x16\x17"
"\x18\x19\x1a\x1b\x1c\x1d\x1e";
int init(void)
{
struct crypto_shash *tfm = NULL;
char *data = NULL, *out = NULL;
tfm = crypto_alloc_shash("poly1305", 0, 0);
data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);
out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);
memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);
kfree(data);
kfree(out);
return 0;
}
void deinit(void)
{
}
module_init(init)
module_exit(deinit)
MODULE_LICENSE("GPL");
The root cause of the bug sits in neon_poly1305_blocks. The logic
neon_poly1305_blocks() performed is that if it was called with both s[]
and r[] uninitialized, it will first try to initialize them with the
data from the first "block" that it believed to be 32 bytes in length.
First 16 bytes are used as the key and the next 16 bytes for s[]. This
would lead to the aforementioned read out-of-bound. However, after
calling poly1305_init_arch(), only 16 bytes were[...]
CVE Monitor
{ "Source": "CVE FEED", "Title": "CVE-2022-50231 - Huawei Crypto Poly1305 Arm64 Out-of-Bounds Read Vulnerability", "Content": "CVE ID : CVE-2022-50231 Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago Description : In the Linux kernel…
deducted from the input
and s[] is initialized yet again with the following 16 bytes. The second
initialization of s[] is certainly redundent which indicates that the
first initialization should be for r[] only.
This patch fixes the issue by calling poly1305_init_arm64() instead o
---truncated---
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 🔹
and s[] is initialized yet again with the following 16 bytes. The second
initialization of s[] is certainly redundent which indicates that the
first initialization should be for r[] only.
This patch fixes the issue by calling poly1305_init_arm64() instead o
---truncated---
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 🔹