Security Vulnerabilities
- CVEs Published In August 2025
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: canaan: k230: add NULL check in DT parse
Add a NULL check for the return value of of_get_property() when
retrieving the "pinmux" property in the group parser. This avoids
a potential NULL pointer dereference if the property is missing
from the device tree node.
Also fix a typo ("sintenel") in the device ID match table comment,
correcting it to "sentinel".
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()
Preserve the error code if iwl_setup_deferred_work() fails. The current
code returns ERR_PTR(0) (which is NULL) on this path. I believe the
missing error code potentially leads to a use after free involving
debugfs.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: mcc: prevent shift wrapping in rtw89_core_mlsr_switch()
The "link_id" value comes from the user via debugfs. If it's larger
than BITS_PER_LONG then that would result in shift wrapping and
potentially an out of bounds access later. In fact, we can limit it
to IEEE80211_MLD_MAX_NUM_LINKS (15).
Fortunately, only root can write to debugfs files so the security
impact is minimal.
In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails
Have nvmet_req_init() and req->execute() complete failed commands.
Description of the problem:
nvmet_req_init() calls __nvmet_req_complete() internally upon failure,
e.g., unsupported opcode, which calls the "queue_response" callback,
this results in nvmet_pci_epf_queue_response() being called, which will
call nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is
different from DMA_TO_DEVICE. This results in a double completion as
nvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()
when nvmet_req_init() fails.
Steps to reproduce:
On the host send a command with an unsupported opcode with nvme-cli,
For example the admin command "security receive"
$ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096
This triggers a double completion as nvmet_req_init() fails and
nvmet_pci_epf_queue_response() is called, here iod->dma_dir is still
in the default state of "DMA_NONE" as set by default in
nvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.
Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also
called in nvmet_pci_epf_exec_iod_work() leading to a double completion.
This not only sends two completions to the host but also corrupts the
state of the PCI NVMe target leading to kernel oops.
This patch lets nvmet_req_init() and req->execute() complete all failed
commands, and removes the double completion case in
nvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where
double completions occurred.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi
The following assertion is triggered on the rtw89 driver startup. It
looks meaningless to hold wiphy lock on the early init stage so drop the
assertion.
WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]
CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy)
Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024
RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]
Call Trace:
<TASK>
rtw89_sar_init+0x68/0x2c0 [rtw89_core]
rtw89_core_init+0x188e/0x1e50 [rtw89_core]
rtw89_pci_probe+0x530/0xb50 [rtw89_pci]
local_pci_probe+0xd9/0x190
pci_call_probe+0x183/0x540
pci_device_probe+0x171/0x2c0
really_probe+0x1e1/0x890
__driver_probe_device+0x18c/0x390
driver_probe_device+0x4a/0x120
__driver_attach+0x1a0/0x530
bus_for_each_dev+0x10b/0x190
bus_add_driver+0x2eb/0x540
driver_register+0x1a3/0x3a0
do_one_initcall+0xd5/0x450
do_init_module+0x2cc/0x8f0
init_module_from_file+0xe1/0x150
idempotent_init_module+0x226/0x760
__x64_sys_finit_module+0xcd/0x150
do_syscall_64+0x94/0x380
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Found by Linux Verification Center (linuxtesting.org).
In the Linux kernel, the following vulnerability has been resolved:
spi: stm32: Check for cfg availability in stm32_spi_probe
The stm32_spi_probe function now includes a check to ensure that the
pointer returned by of_device_get_match_data is not NULL before
accessing its members. This resolves a warning where a potential NULL
pointer dereference could occur when accessing cfg->has_device_mode.
Before accessing the 'has_device_mode' member, we verify that 'cfg' is
not NULL. If 'cfg' is NULL, an error message is logged.
This change ensures that the driver does not attempt to access
configuration data if it is not available, thus preventing a potential
system crash due to a NULL pointer dereference.
In the Linux kernel, the following vulnerability has been resolved:
arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight
An infinite loop has been created by the Coresight devices. When only a
source device is enabled, the coresight_find_activated_sysfs_sink function
is recursively invoked in an attempt to locate an active sink device,
ultimately leading to a stack overflow and system crash. Therefore, disable
the replicator1 to break the infinite loop and prevent a potential stack
overflow.
replicator1_out -> funnel_swao_in6 -> tmc_etf_swao_in -> tmc_etf_swao_out
| |
replicator1_in replicator_swao_in
| |
replicator0_out1 replicator_swao_out0
| |
replicator0_in funnel_in1_in3
| |
tmc_etf_out <- tmc_etf_in <- funnel_merg_out <- funnel_merg_in1 <- funnel_in1_out
[call trace]
dump_backtrace+0x9c/0x128
show_stack+0x20/0x38
dump_stack_lvl+0x48/0x60
dump_stack+0x18/0x28
panic+0x340/0x3b0
nmi_panic+0x94/0xa0
panic_bad_stack+0x114/0x138
handle_bad_stack+0x34/0xb8
__bad_stack+0x78/0x80
coresight_find_activated_sysfs_sink+0x28/0xa0 [coresight]
coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]
coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]
coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]
coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]
...
coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]
coresight_enable_sysfs+0x80/0x2a0 [coresight]
side effect after the change:
Only trace data originating from AOSS can reach the ETF_SWAO and EUD sinks.
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: remove mutex_lock check in hfsplus_free_extents
Syzbot reported an issue in hfsplus filesystem:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346
hfsplus_free_extents+0x700/0xad0
Call Trace:
<TASK>
hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606
hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56
cont_expand_zero fs/buffer.c:2383 [inline]
cont_write_begin+0x2cf/0x860 fs/buffer.c:2446
hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52
generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347
hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263
notify_change+0xe38/0x10f0 fs/attr.c:420
do_truncate+0x1fb/0x2e0 fs/open.c:65
do_sys_ftruncate+0x2eb/0x380 fs/open.c:193
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock
on file truncation") unlock extree before hfsplus_free_extents(),
and add check wheather extree is locked in hfsplus_free_extents().
However, when operations such as hfsplus_file_release,
hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed
concurrently in different files, it is very likely to trigger the
WARN_ON, which will lead syzbot and xfstest to consider it as an
abnormality.
The comment above this warning also describes one of the easy
triggering situations, which can easily trigger and cause
xfstest&syzbot to report errors.
[task A] [task B]
->hfsplus_file_release
->hfsplus_file_truncate
->hfs_find_init
->mutex_lock
->mutex_unlock
->hfsplus_write_begin
->hfsplus_get_block
->hfsplus_file_extend
->hfsplus_ext_read_extent
->hfs_find_init
->mutex_lock
->hfsplus_free_extents
WARN_ON(mutex_is_locked) !!!
Several threads could try to lock the shared extents tree.
And warning can be triggered in one thread when another thread
has locked the tree. This is the wrong behavior of the code and
we need to remove the warning.
In the Linux kernel, the following vulnerability has been resolved:
landlock: Fix warning from KUnit tests
get_id_range() expects a positive value as first argument but
get_random_u8() can return 0. Fix this by clamping it.
Validated by running the test in a for loop for 1000 times.
Note that MAX() is wrong as it is only supposed to be used for
constants, but max() is good here.
[..] ok 9 test_range2_rand1
[..] ok 10 test_range2_rand2
[..] ok 11 test_range2_rand15
[..] ------------[ cut here ]------------
[..] WARNING: CPU: 6 PID: 104 at security/landlock/id.c:99 test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))
[..] Modules linked in:
[..] CPU: 6 UID: 0 PID: 104 Comm: kunit_try_catch Tainted: G N 6.16.0-rc1-dev-00001-g314a2f98b65f #1 PREEMPT(undef)
[..] Tainted: [N]=TEST
[..] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[..] RIP: 0010:test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))
[..] Code: 49 c7 c0 10 70 30 82 4c 89 ff 48 c7 c6 a0 63 1e 83 49 c7 45 a0 e0 63 1e 83 e8 3f 95 17 00 e9 1f ff ff ff 0f 0b e9 df fd ff ff <0f> 0b ba 01 00 00 00 e9 68 fe ff ff 49 89 45 a8 49 8d 4d a0 45 31
[..] RSP: 0000:ffff888104eb7c78 EFLAGS: 00010246
[..] RAX: 0000000000000000 RBX: 000000000870822c RCX: 0000000000000000
^^^^^^^^^^^^^^^^
[..]
[..] Call Trace:
[..]
[..] ---[ end trace 0000000000000000 ]---
[..] ok 12 test_range2_rand16
[..] # landlock_id: pass:12 fail:0 skip:0 total:12
[..] # Totals: pass:12 fail:0 skip:0 total:12
[..] ok 1 landlock_id
[mic: Minor cosmetic improvements]
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable migration in nf_hook_run_bpf().
syzbot reported that the netfilter bpf prog can be called without
migration disabled in xmit path.
Then the assertion in __bpf_prog_run() fails, triggering the splat
below. [0]
Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().
[0]:
BUG: assuming non migratable context at ./include/linux/filter.h:703
in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session
3 locks held by sshd-session/5829:
#0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]
#0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395
#1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
#1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470
#2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
#2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241
CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
__cant_migrate kernel/sched/core.c:8860 [inline]
__cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834
__bpf_prog_run include/linux/filter.h:703 [inline]
bpf_prog_run include/linux/filter.h:725 [inline]
nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20
nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]
nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623
nf_hook+0x370/0x680 include/linux/netfilter.h:272
NF_HOOK_COND include/linux/netfilter.h:305 [inline]
ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433
dst_output include/net/dst.h:459 [inline]
ip_local_out net/ipv4/ip_output.c:129 [inline]
__ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527
__tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479
tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]
tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838
__tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021
tcp_push+0x225/0x700 net/ipv4/tcp.c:759
tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359
tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396
inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg net/socket.c:727 [inline]
sock_write_iter+0x4aa/0x5b0 net/socket.c:1131
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x6c7/0x1150 fs/read_write.c:686
ksys_write+0x1f8/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe7d365d407
Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: