{
"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 🔹

{
"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-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[...]

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 🔹

{
"Source": "CVE FEED",
"Title": "CVE-2022-50232 - Linux Kernel ARM64 UXN Set Vulnerability",
"Content": "CVE ID : CVE-2022-50232
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-50222 - Linux Kernel TTY Unicode Screen Buffer Info Leak",
"Content": "CVE ID : CVE-2022-50222
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

tty: vt: initialize unicode screen buffer

syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read
immediately after resize operation. Initialize buffer using kzalloc().

----------
#include
#include
#include
#include

int main(int argc, char *argv[])
{
struct fb_var_screeninfo var = { };
const int fb_fd = open("/dev/fb0", 3);
ioctl(fb_fd, FBIOGET_VSCREENINFO, &var);
var.yres = 0x21;
ioctl(fb_fd, FBIOPUT_VSCREENINFO, &var);
return read(open("/dev/vcsu", O_RDONLY), &var, sizeof(var)) == -1;
}
----------
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-50223 - LoongArch Linux Kernel CPUInfo Information Disclosure Vulnerability",
"Content": "CVE ID : CVE-2022-50223
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

LoongArch: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK

When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
cpu_max_bits_warn() generates a runtime warning similar as below while
we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
instead of NR_CPUS to iterate CPUs.

[ 3.052463] ------------[ cut here ]------------
[ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
[ 3.070072] Modules linked in: efivarfs autofs4
[ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
[ 3.084034] Hardware name: Loongson Loongson-3A5000-7A1000-1w-V0.1-CRB/Loongson-LS3A5000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27
[ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
[ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
[ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
[ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
[ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
[ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
[ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
[ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000
[ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
[ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
[ 3.195868] ...
[ 3.199917] Call Trace:
[ 3.203941] [<90000000002086d8] show_stack+0x38/0x14c
[ 3.210666] [<9000000000cf846c] dump_stack_lvl+0x60/0x88
[ 3.217625] [<900000000023d268] __warn+0xd0/0x100
[ 3.223958] [<9000000000cf3c90] warn_slowpath_fmt+0x7c/0xcc
[ 3.231150] [<9000000000210220] show_cpuinfo+0x5e8/0x5f0
[ 3.238080] [<90000000004f578c] seq_read_iter+0x354/0x4b4
[ 3.245098] [<90000000004c2e90] new_sync_read+0x17c/0x1c4
[ 3.252114] [<90000000004c5174] vfs_read+0x138/0x1d0
[ 3.258694] [<90000000004c55f8] ksys_read+0x70/0x100
[ 3.265265] [<9000000000cfde9c] do_syscall+0x7c/0x94
[ 3.271820] [<9000000000202fe4] handle_syscall+0xc4/0x160
[ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
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-50224 - "KVM: AMD SVM NX Bit Validation Vulnerability"",
"Content": "CVE ID : CVE-2022-50224
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT

Treat the NX bit as valid when using NPT, as KVM will set the NX bit when
the NX huge page mitigation is enabled (mindblowing) and trigger the WARN
that fires on reserved SPTE bits being set.

KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:
Refuse to load kvm_amd if NX support is not available") for exactly this
reason, but apparently it never occurred to anyone to actually test NPT
with the mitigation enabled.

------------[ cut here ]------------
spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000
WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm]
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022
RIP: 0010:make_spte+0x327/0x340 [kvm]
Call Trace:

tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm]
kvm_tdp_mmu_map+0x343/0x3b0 [kvm]
direct_page_fault+0x1ae/0x2a0 [kvm]
kvm_tdp_page_fault+0x7d/0x90 [kvm]
kvm_mmu_page_fault+0xfb/0x2e0 [kvm]
npf_interception+0x55/0x90 [kvm_amd]
svm_invoke_exit_handler+0x31/0xf0 [kvm_amd]
svm_handle_exit+0xf6/0x1d0 [kvm_amd]
vcpu_enter_guest+0xb6d/0xee0 [kvm]
? kvm_pmu_trigger_event+0x6d/0x230 [kvm]
vcpu_run+0x65/0x2c0 [kvm]
kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm]
kvm_vcpu_ioctl+0x551/0x610 [kvm]
__se_sys_ioctl+0x77/0xc0
__x64_sys_ioctl+0x1d/0x20
do_syscall_64+0x44/0xa0
entry_SYSCALL_64_after_hwframe+0x46/0xb0

---[ end trace 0000000000000000 ]---
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-50225 - RISC-V Linux Kernel Uprobe SR SPIE Handling Vulnerability",
"Content": "CVE ID : CVE-2022-50225
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

riscv:uprobe fix SR_SPIE set/clear handling

In riscv the process of uprobe going to clear spie before exec
the origin insn,and set spie after that.But When access the page
which origin insn has been placed a page fault may happen and
irq was disabled in arch_uprobe_pre_xol function,It cause a WARN
as follows.
There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.
We can just remove it.

[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488
[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work
[ 31.684929] preempt_count: 0, expected: 0
[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G
[ 31.686542] Hardware name: riscv-virtio,qemu (DT)
[ 31.686797] Call Trace:
[ 31.687053] [] dump_backtrace+0x30/0x38
[ 31.687699] [] show_stack+0x40/0x4c
[ 31.688141] [] dump_stack_lvl+0x44/0x5c
[ 31.688396] [] dump_stack+0x18/0x20
[ 31.688653] [] __might_resched+0x114/0x122
[ 31.688948] [] __might_sleep+0x50/0x7a
[ 31.689435] [] down_read+0x30/0x130
[ 31.689728] [] do_page_fault+0x166/x446
[ 31.689997] [] ret_from_exception+0x0/0xc
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-50226 - Linux Kernel - CCP Kernel Memory Leak Vulnerability",
"Content": "CVE ID : CVE-2022-50226
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: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak

For some sev ioctl interfaces, input may be passed that is less than or
equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP
firmware returns. In this case, kmalloc will allocate memory that is the
size of the input rather than the size of the data. Since PSP firmware
doesn't fully overwrite the buffer, the sev ioctl interfaces with the
issue may return uninitialized slab memory.

Currently, all of the ioctl interfaces in the ccp driver are safe, but
to prevent future problems, change all ioctl interfaces that allocate
memory with kmalloc to use kzalloc and memset the data buffer to zero
in sev_ioctl_do_platform_status.
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-50227 - "KVM Xen Timer Initialization Vulnerability"",
"Content": "CVE ID : CVE-2022-50227
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/xen: Initialize Xen timer only once

Add a check for existing xen timers before initializing a new one.

Currently kvm_xen_init_timer() is called on every
KVM_XEN_VCPU_ATTR_TYPE_TIMER, which is causing the following ODEBUG
crash when vcpu->arch.xen.timer is already set.

ODEBUG: init active (active state 0)
object type: hrtimer hint: xen_timer_callbac0
RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:502
Call Trace:
__debug_object_init
debug_hrtimer_init
debug_init
hrtimer_init
kvm_xen_init_timer
kvm_xen_vcpu_set_attr
kvm_arch_vcpu_ioctl
kvm_vcpu_ioctl
vfs_ioctl
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-50228 - QEMU KVM SVM Invalid Interrupt Injection Vulnerability",
"Content": "CVE ID : CVE-2022-50228
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0

Don't BUG/WARN on interrupt injection due to GIF being cleared,
since it's trivial for userspace to force the situation via
KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct
for KVM internally generated injections).

kernel BUG at arch/x86/kvm/svm/svm.c:3386!
invalid opcode: 0000 [#1] SMP
CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]
Code: <0f0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53
RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006
RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0
RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000
FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0
Call Trace:

inject_pending_event+0x2f7/0x4c0 [kvm]
kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm]
kvm_vcpu_ioctl+0x26d/0x650 [kvm]
__x64_sys_ioctl+0x82/0xb0
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
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-50229 - ALSA bcd2000 Use-After-Free Vulnerability",
"Content": "CVE ID : CVE-2022-50229
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

ALSA: bcd2000: Fix a UAF bug on the error path of probing

When the driver fails in snd_card_register() at probe time, it will free
the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug.

The following log can reveal it:

[ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]
[ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0
[ 50.729530] Call Trace:
[ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]

Fix this by adding usb_kill_urb() before usb_free_urb().
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-50221 - Linux Kernel DRM/FB-Helper Out-of-Bounds Access Vulnerability",
"Content": "CVE ID : CVE-2022-50221
Published : June 18, 2025, 11:15 a.m. | 1 hour, 27 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:

drm/fb-helper: Fix out-of-bounds access

Clip memory range to screen-buffer size to avoid out-of-bounds access
in fbdev deferred I/O's damage handling.

Fbdev's deferred I/O can only track pages. From the range of pages, the
damage handler computes the clipping rectangle for the display update.
If the fbdev screen buffer ends near the beginning of a page, that page
could contain more scanlines. The damage handler would then track these
non-existing scanlines as dirty and provoke an out-of-bounds access
during the screen update. Hence, clip the maximum memory range to the
size of the screen buffer.

While at it, rename the variables min/max to min_off/max_off in
drm_fb_helper_deferred_io(). This avoids confusion with the macros of
the same name.
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 🔹