CVE ID : CVE-2025-38169

Published : July 3, 2025, 9:15 a.m. | 2 hours, 14 minutes ago

Description : In the Linux kernel, the following vulnerability has been resolved:

arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP

On system with SME, a thread’s kernel FPSIMD state may be erroneously
clobbered during a context switch immediately after that state is
restored. Systems without SME are unaffected.

If the CPU happens to be in streaming SVE mode before a context switch
to a thread with kernel FPSIMD state, fpsimd_thread_switch() will
restore the kernel FPSIMD state using fpsimd_load_kernel_state() while
the CPU is still in streaming SVE mode. When fpsimd_thread_switch()
subsequently calls fpsimd_flush_cpu_state(), this will execute an
SMSTOP, causing an exit from streaming SVE mode. The exit from
streaming SVE mode will cause the hardware to reset a number of
FPSIMD/SVE/SME registers, clobbering the FPSIMD state.

Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel
FPSIMD state.

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-38170

Published : July 3, 2025, 9:15 a.m. | 2 hours, 14 minutes ago

Description : In the Linux kernel, the following vulnerability has been resolved:

arm64/fpsimd: Discard stale CPU state when handling SME traps

The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state
incorrectly, and a race with preemption can result in a task having
TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SME traps enabled). This can result in warnings from
do_sme_acc() where SME traps are not expected while TIF_SME is set:

| /* With TIF_SME userspace shouldn’t generate any traps */
| if (test_and_set_thread_flag(TIF_SME))
| WARN_ON(1);

This is very similar to the SVE issue we fixed in commit:

751ecf6afd6568ad (“arm64/sve: Discard stale CPU state when handling SVE traps”)

The race can occur when the SME trap handler is preempted before and
after manipulating the saved FPSIMD/SVE/SME state, starting and ending on
the same CPU, e.g.

| void do_sme_acc(unsigned long esr, struct pt_regs *regs)
| {
| // Trap on CPU 0 with TIF_SME clear, SME traps enabled
| // task->fpsimd_cpu is 0.
| // per_cpu_ptr(&fpsimd_last_state, 0) is task.
|
| …
|
| // Preempted; migrated from CPU 0 to CPU 1.
| // TIF_FOREIGN_FPSTATE is set.
|
| get_cpu_fpsimd_context();
|
| /* With TIF_SME userspace shouldn’t generate any traps */
| if (test_and_set_thread_flag(TIF_SME))
| WARN_ON(1);
|
| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
| unsigned long vq_minus_one =
| sve_vq_from_vl(task_get_sme_vl(current)) – 1;
| sme_set_vq(vq_minus_one);
|
| fpsimd_bind_task_to_cpu();
| }
|
| put_cpu_fpsimd_context();
|
| // Preempted; migrated from CPU 1 to CPU 0.
| // task->fpsimd_cpu is still 0
| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
| // – Stale HW state is reused (with SME traps enabled)
| // – TIF_FOREIGN_FPSTATE is cleared
| // – A return to userspace skips HW state restore
| }

Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() to detach from the saved CPU
state. This ensures that a subsequent context switch will not reuse the
stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace.

Note: this was originallly posted as [1].

[ Rutland: rewrite commit message ]

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-38171

Published : July 3, 2025, 9:15 a.m. | 2 hours, 14 minutes ago

Description : In the Linux kernel, the following vulnerability has been resolved:

power: supply: max77705: Fix workqueue error handling in probe

The create_singlethread_workqueue() doesn’t return error pointers, it
returns NULL. Also cleanup the workqueue on the error paths.

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-38172

Published : July 3, 2025, 9:15 a.m. | 2 hours, 14 minutes ago

Description : In the Linux kernel, the following vulnerability has been resolved:

erofs: avoid using multiple devices with different type

For multiple devices, both primary and extra devices should be the
same type. `erofs_init_device` has already guaranteed that if the
primary is a file-backed device, extra devices should also be
regular files.

However, if the primary is a block device while the extra device
is a file-backed device, `erofs_init_device` will get an ENOTBLK,
which is not treated as an error in `erofs_fc_get_tree`, and that
leads to an UAF:

erofs_fc_get_tree
get_tree_bdev_flags(erofs_fc_fill_super)
erofs_read_superblock
erofs_init_device // sbi->dif0 is not inited yet,
// return -ENOTBLK
deactivate_locked_super
free(sbi)
if (err is -ENOTBLK)
sbi->dif0.file = filp_open() // sbi UAF

So if -ENOTBLK is hitted in `erofs_init_device`, it means the
primary device must be a block device, and the extra device
is not a block device. The error can be converted to -EINVAL.

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-38166

Published : July 3, 2025, 9:15 a.m. | 2 hours, 14 minutes ago

Description : In the Linux kernel, the following vulnerability has been resolved:

bpf: fix ktls panic with sockmap

[ 2172.936997] ————[ cut here ]————
[ 2172.936999] kernel BUG at lib/iov_iter.c:629!
……
[ 2172.944996] PKRU: 55555554
[ 2172.945155] Call Trace:
[ 2172.945299]
[ 2172.945428] ? die+0x36/0x90
[ 2172.945601] ? do_trap+0xdd/0x100
[ 2172.945795] ? iov_iter_revert+0x178/0x180
[ 2172.946031] ? iov_iter_revert+0x178/0x180
[ 2172.946267] ? do_error_trap+0x7d/0x110
[ 2172.946499] ? iov_iter_revert+0x178/0x180
[ 2172.946736] ? exc_invalid_op+0x50/0x70
[ 2172.946961] ? iov_iter_revert+0x178/0x180
[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20
[ 2172.947446] ? iov_iter_revert+0x178/0x180
[ 2172.947683] ? iov_iter_revert+0x5c/0x180
[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840
[ 2172.948206] tls_sw_sendmsg+0x52/0x80
[ 2172.948420] ? inet_sendmsg+0x1f/0x70
[ 2172.948634] __sys_sendto+0x1cd/0x200
[ 2172.948848] ? find_held_lock+0x2b/0x80
[ 2172.949072] ? syscall_trace_enter+0x140/0x270
[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170
[ 2172.949595] ? find_held_lock+0x2b/0x80
[ 2172.949817] ? syscall_trace_enter+0x140/0x270
[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190
[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0
[ 2172.951036] __x64_sys_sendto+0x24/0x30
[ 2172.951382] do_syscall_64+0x90/0x170
……

After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,
e.g., when the BPF program executes bpf_msg_push_data().

If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,
it will return -ENOSPC and attempt to roll back to the non-zero copy
logic. However, during rollback, msg->msg_iter is reset, but since
msg_pl->sg.size has been increased, subsequent executions will exceed the
actual size of msg_iter.
”’
iov_iter_revert(&msg->msg_iter, msg_pl->sg.size – orig_size);
”’

The changes in this commit are based on the following considerations:

1. When cork_bytes is set, rolling back to non-zero copy logic is
pointless and can directly go to zero-copy logic.

2. We can not calculate the correct number of bytes to revert msg_iter.

Assume the original data is “abcdefgh” (8 bytes), and after 3 pushes
by the BPF program, it becomes 11-byte data: “abc?de?fgh?”.
Then, we set cork_bytes to 6, which means the first 6 bytes have been
processed, and the remaining 5 bytes “?fgh?” will be cached until the
length meets the cork_bytes requirement.

However, some data in “?fgh?” is not within ‘sg->msg_iter’
(but in msg_pl instead), especially the data “?” we pushed.

So it doesn’t seem as simple as just reverting through an offset of
msg_iter.

3. For non-TLS sockets in tcp_bpf_sendmsg, when a “cork” situation occurs,
the user-space send() doesn’t return an error, and the returned length is
the same as the input length parameter, even if some data is cached.

Additionally, I saw that the current non-zero-copy logic for handling
corking is written as:
”’
line 1177
else if (ret != -EAGAIN) {
if (ret == -ENOSPC)
ret = 0;
goto send_end;
”’

So it’s ok to just return ‘copied’ without error when a “cork” situation
occurs.

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-38168

Published : July 3, 2025, 9:15 a.m. | 2 hours, 14 minutes ago

Description : In the Linux kernel, the following vulnerability has been resolved:

perf: arm-ni: Unregister PMUs on probe failure

When a resource allocation fails in one clock domain of an NI device,
we need to properly roll back all previously registered perf PMUs in
other clock domains of the same device.

Otherwise, it can lead to kernel panics.

Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374
arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000
arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16
list_add corruption: next->prev should be prev (fffffd01e9698a18),
but was 0000000000000000. (next=ffff10001a0decc8).
pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=–)
pc : list_add_valid_or_report+0x7c/0xb8
lr : list_add_valid_or_report+0x7c/0xb8
Call trace:
__list_add_valid_or_report+0x7c/0xb8
perf_pmu_register+0x22c/0x3a0
arm_ni_probe+0x554/0x70c [arm_ni]
platform_probe+0x70/0xe8
really_probe+0xc6/0x4d8
driver_probe_device+0x48/0x170
__driver_attach+0x8e/0x1c0
bus_for_each_dev+0x64/0xf0
driver_add+0x138/0x260
bus_add_driver+0x68/0x138
__platform_driver_register+0x2c/0x40
arm_ni_init+0x14/0x2a [arm_ni]
do_init_module+0x36/0x298
—[ end trace 0000000000000000 ]—
Kernel panic – not syncing: Oops – BUG: Fatal exception
SMP: stopping secondary CPUs

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-38173

Published : July 3, 2025, 9:15 a.m. | 2 hours, 14 minutes ago

Description : In the Linux kernel, the following vulnerability has been resolved:

crypto: marvell/cesa – Handle zero-length skcipher requests

Do not access random memory for zero-length skcipher requests.
Just return 0.

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2024-5647

Published : July 3, 2025, 10:15 a.m. | 1 hour, 14 minutes ago

Description : Multiple plugins for WordPress are vulnerable to Stored Cross-Site Scripting via the plugin’s bundled Magnific Popups library (version 1.1.0) in various versions due to insufficient input sanitization and output escaping on user supplied attributes. 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. NOTE: This vulnerability was fixed in the upstream library (Magnific Popups version 1.2.0) by disabling the loading of HTML within certain fields by default.

Severity: 6.4 | MEDIUM

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-0885

Published : July 3, 2025, 10:15 a.m. | 1 hour, 14 minutes ago

Description : Incorrect Authorization vulnerability in OpenText™ GroupWise allows Exploiting Incorrectly Configured Access Control Security Levels.

The vulnerability could allow unauthorized access to calendar items marked private.

This issue affects GroupWise versions 7 through 17.5, 23.4, 24.1, 24.2, 24.3, 24.4.

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

CVE ID : CVE-2025-6587

Published : July 3, 2025, 10:15 a.m. | 1 hour, 14 minutes ago

Description : System environment variables are recorded in Docker Desktop diagnostic logs, when using shell auto-completion. This leads to unintentional disclosure of sensitive information such as api keys, passwords, etc. 
A malicious actor with read access to these logs could obtain secrets and further use them to gain unauthorized access to other systems. Starting with version 4.43.0 Docker Desktop no longer logs system environment variables as part of diagnostics log collection.

Severity: 0.0 | NA

Visit the link for more details, such as CVSS details, affected products, timeline, and more…

Actively Exploited Google Chrome Zero-Day (CVE-2025-6554) Added to CISA’s KEV Catalog, PoC Available

🔐 Access to This Vulnerability Report Requires Support
This article is available to verified supporters only – contribute to read the full report
Contribute with Google
Or choose another support optio …
Read more

Published Date:
Jul 03, 2025 (5 hours, 6 minutes ago)

Vulnerabilities has been mentioned in this article.

CVE-2025-6554

CVE-2025-20309 affects Cisco Unified CM

Skip to content🔎 Vulnerability OverviewCVE ID: CVE-2025-20309Severity: Critical (CVSS v3.1 Score: 10.0)Discovered in: Cisco Unified Communications Manager (Unified CM) and Session Management Edition ( …
Read more

Published Date:
Jul 03, 2025 (5 hours, 2 minutes ago)

Vulnerabilities has been mentioned in this article.

CVE-2025-20309

CVE-2025-6554

CVE-2025-20156

Burn It With Fire: How to Eliminate an Industry-Wide Supply Chain Vulnerability

🔥 The supply chain bug that couldn’t be ignored — so I torched itIntroduction: A Typo That Could Compromise the JVMIn 2019, while debugging one of my own builds, I noticed something odd. The build was …
Read more

Published Date:
Jul 03, 2025 (2 hours, 50 minutes ago)

Vulnerabilities has been mentioned in this article.