Linux: >> Linux Kernel >> 6.1.19 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix double-free on mc_dev
The blamed commit tried to simplify how the deallocations are done but,
in the process, introduced a double-free on the mc_dev variable.
In case the MC device is a DPRC, a new mc_bus is allocated and the
mc_dev variable is just a reference to one of its fields. In this
circumstance, on the error path only the mc_bus should be freed.
This commit introduces back the following checkpatch warning which is a
false-positive.
WARNING: kfree(NULL) is safe and this check is probably not required
+ if (mc_bus)
+ kfree(mc_bus);
CVSS Score
7.8
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and
atomctrl_initialize_mc_reg_table_v2_2() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table()
fails to retrieve vram_info, it returns NULL which is later
dereferenced.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: eir: Fix possible crashes on eir_create_adv_data
eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER
without checking if that would fit.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix NULL pointer deference on eir_get_service_data
The len parameter is considered optional so it can be NULL so it cannot
be used for skipping to next entry of EIR_SERVICE_DATA.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()
There is no disagreement that we should check both ptp->is_virtual_clock
and ptp->n_vclocks to check if the ptp virtual clock is in use.
However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in
ptp_vclock_in_use(), we observe a recursive lock in the call trace
starting from n_vclocks_store().
============================================
WARNING: possible recursive locking detected
6.15.0-rc6 #1 Not tainted
--------------------------------------------
syz.0.1540/13807 is trying to acquire lock:
ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]
ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415
but task is already holding lock:
ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ptp->n_vclocks_mux);
lock(&ptp->n_vclocks_mux);
*** DEADLOCK ***
....
============================================
The best way to solve this is to remove the logic that checks
ptp->n_vclocks in ptp_vclock_in_use().
The reason why this is appropriate is that any path that uses
ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater
than 0 before unregistering vclocks, and all functions are already
written this way. And in the function that uses ptp->n_vclocks, we
already get ptp->n_vclocks_mux before unregistering vclocks.
Therefore, we need to remove the redundant check for ptp->n_vclocks in
ptp_vclock_in_use() to prevent recursive locking.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
seg6: Fix validation of nexthop addresses
The kernel currently validates that the length of the provided nexthop
address does not exceed the specified length. This can lead to the
kernel reading uninitialized memory if user space provided a shorter
length than the specified one.
Fix by validating that the provided length exactly matches the specified
one.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()
Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():
1] If dma_map_sg() fails for areq->dst, the device driver would try to free
DMA memory it has not allocated in the first place. To fix this, on the
"theend_sgs" error path, call dma unmap only if the corresponding dma
map was successful.
2] If the dma_map_single() call for the IV fails, the device driver would
try to free an invalid DMA memory address on the "theend_iv" path:
------------[ cut here ]------------
DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address
WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90
Modules linked in: skcipher_example(O+)
CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT
Tainted: [O]=OOT_MODULE
Hardware name: OrangePi Zero2 (DT)
pc : check_unmap+0x123c/0x1b90
lr : check_unmap+0x123c/0x1b90
...
Call trace:
check_unmap+0x123c/0x1b90 (P)
debug_dma_unmap_page+0xac/0xc0
dma_unmap_page_attrs+0x1f4/0x5fc
sun8i_ce_cipher_do_one+0x1bd4/0x1f40
crypto_pump_work+0x334/0x6e0
kthread_worker_fn+0x21c/0x438
kthread+0x374/0x664
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
To fix this, check for !dma_mapping_error() before calling
dma_unmap_single() on the "theend_iv" path.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: at91: Fix possible out-of-boundary access
at91_gpio_probe() doesn't check that given OF alias is not available or
something went wrong when trying to get it. This might have consequences
when accessing gpio_chips array with that value as an index. Note, that
BUG() can be compiled out and hence won't actually perform the required
checks.
CVSS Score
7.1
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix node corruption in ar->arvifs list
In current WLAN recovery code flow, ath11k_core_halt() only
reinitializes the "arvifs" list head. This will cause the
list node immediately following the list head to become an
invalid list node. Because the prev of that node still points
to the list head "arvifs", but the next of the list head "arvifs"
no longer points to that list node.
When a WLAN recovery occurs during the execution of a vif
removal, and it happens before the spin_lock_bh(&ar->data_lock)
in ath11k_mac_op_remove_interface(), list_del() will detect the
previously mentioned situation, thereby triggering a kernel panic.
The fix is to remove and reinitialize all vif list nodes from the
list head "arvifs" during WLAN halt. The reinitialization is to make
the list nodes valid, ensuring that the list_del() in
ath11k_mac_op_remove_interface() can execute normally.
Call trace:
__list_del_entry_valid_or_report+0xb8/0xd0
ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]
drv_remove_interface+0x48/0x194 [mac80211]
ieee80211_do_stop+0x6e0/0x844 [mac80211]
ieee80211_stop+0x44/0x17c [mac80211]
__dev_close_many+0xac/0x150
__dev_change_flags+0x194/0x234
dev_change_flags+0x24/0x6c
devinet_ioctl+0x3a0/0x670
inet_ioctl+0x200/0x248
sock_do_ioctl+0x60/0x118
sock_ioctl+0x274/0x35c
__arm64_sys_ioctl+0xac/0xf0
invoke_syscall+0x48/0x114
...
Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10
In the Linux kernel, the following vulnerability has been resolved:
mtd: nand: ecc-mxic: Fix use of uninitialized variable ret
If ctx->steps is zero, the loop processing ECC steps is skipped,
and the variable ret remains uninitialized. It is later checked
and returned, which leads to undefined behavior and may cause
unpredictable results in user space or kernel crashes.
This scenario can be triggered in edge cases such as misconfigured
geometry, ECC engine misuse, or if ctx->steps is not validated
after initialization.
Initialize ret to zero before the loop to ensure correct and safe
behavior regardless of the ctx->steps value.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-07-10