Security Vulnerabilities - CVEs Published In June 2025
In the Linux kernel, the following vulnerability has been resolved:
soundwire: revisit driver bind/unbind and callbacks
In the SoundWire probe, we store a pointer from the driver ops into
the 'slave' structure. This can lead to kernel oopses when unbinding
codec drivers, e.g. with the following sequence to remove machine
driver and codec driver.
/sbin/modprobe -r snd_soc_sof_sdw
/sbin/modprobe -r snd_soc_rt711
The full details can be found in the BugLink below, for reference the
two following examples show different cases of driver ops/callbacks
being invoked after the driver .remove().
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150
kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]
kernel: RIP: 0010:mutex_lock+0x19/0x30
kernel: Call Trace:
kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]
kernel: ? newidle_balance+0x26a/0x400
kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]
kernel: BUG: unable to handle page fault for address: ffffffffc07654c8
kernel: Workqueue: pm pm_runtime_work
kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]
kernel: Call Trace:
kernel: <TASK>
kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]
kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd]
kernel: ? dpm_sysfs_remove+0x60/0x60
This was not detected earlier in Intel tests since the tests first
remove the parent PCI device and shut down the bus. The sequence
above is a corner case which keeps the bus operational but without a
driver bound.
While trying to solve this kernel oopses, it became clear that the
existing SoundWire bus does not deal well with the unbind case.
Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields")
added a 'probed' status variable and a 'probe_complete'
struct completion. This status is however not reset on remove and
likewise the 'probe complete' is not re-initialized, so the
bind/unbind/bind test cases would fail. The timeout used before the
'update_status' callback was also a bad idea in hindsight, there
should really be no timing assumption as to if and when a driver is
bound to a device.
An initial draft was based on device_lock() and device_unlock() was
tested. This proved too complicated, with deadlocks created during the
suspend-resume sequences, which also use the same device_lock/unlock()
as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS
caused spurious resumes and the use of device_lock() caused hangs
during suspend. After multiple weeks or testing and painful
reverse-engineering of deadlocks on different devices, we looked for
alternatives that did not interfere with the device core.
A bus notifier was used successfully to keep track of DRIVER_BOUND and
DRIVER_UNBIND events. This solved the bind-unbind-bind case in tests,
but it can still be defeated with a theoretical corner case where the
memory is freed by a .remove while the callback is in use. The
notifier only helps make sure the driver callbacks are valid, but not
that the memory allocated in probe remains valid while the callbacks
are invoked.
This patch suggests the introduction of a new 'sdw_dev_lock' mutex
protecting probe/remove and all driver callbacks. Since this mutex is
'local' to SoundWire only, it does not interfere with existing locks
and does not create deadlocks. In addition, this patch removes the
'probe_complete' completion, instead we directly invoke the
'update_status' from the probe routine. That removes any sort of
timing dependency and a much better support for the device/driver
model, the driver could be bound before the bus started, or eons after
the bus started and the hardware would be properly initialized in all
cases.
BugLink: https://github.com/thesofproject/linux/is
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: sf-pdma: Add multithread support for a DMA channel
When we get a DMA channel and try to use it in multiple threads it
will cause oops and hanging the system.
% echo 64 > /sys/module/dmatest/parameters/threads_per_chan
% echo 10000 > /sys/module/dmatest/parameters/iterations
% echo 1 > /sys/module/dmatest/parameters/run
[ 89.480664] Unable to handle kernel NULL pointer dereference at virtual
address 00000000000000a0
[ 89.488725] Oops [#1]
[ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted
5.17.0-rc5
[ 89.509385] epc : vchan_find_desc+0x32/0x46
[ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6
This happens because of data race. Each thread rewrite channels's
descriptor as soon as device_prep_dma_memcpy() is called. It leads to the
situation when the driver thinks that it uses right descriptor that
actually is freed or substituted for other one.
With current fixes a descriptor changes its value only when it has
been used. A new descriptor is acquired from vc->desc_issued queue that
is already filled with descriptors that are ready to be sent. Threads
have no direct access to DMA channel descriptor. Now it is just possible
to queue a descriptor for further processing.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors
If dw_pcie_ep_init() fails to perform any action after the EPC memory is
initialized and the MSI memory region is allocated, the latter parts won't
be undone thus causing a memory leak. Add a cleanup-on-error path to fix
these leaks.
[bhelgaas: commit log]
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix get_nodes out of bound access
When user specified more nodes than supported, get_nodes will access nmask
array out of bounds.
CVSS Score
7.1
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
kernfs: fix potential NULL dereference in __kernfs_remove
When lockdep is enabled, lockdep_assert_held_write would
cause potential NULL pointer dereference.
Fix the following smatch warnings:
fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check 'kn' (see line 1346)
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
In __driver_attach function, The lock holding logic is as follows:
...
__driver_attach
if (driver_allows_async_probing(drv))
device_lock(dev) // get lock dev
async_schedule_dev(__driver_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__driver_attach_async_helper will get lock dev as
will, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000
[ 370.788865] Call Trace:
[ 370.789374] <TASK>
[ 370.789841] __schedule+0x482/0x1050
[ 370.790613] schedule+0x92/0x1a0
[ 370.791290] schedule_preempt_disabled+0x2c/0x50
[ 370.792256] __mutex_lock.isra.0+0x757/0xec0
[ 370.793158] __mutex_lock_slowpath+0x1f/0x30
[ 370.794079] mutex_lock+0x50/0x60
[ 370.794795] __device_driver_lock+0x2f/0x70
[ 370.795677] ? driver_probe_device+0xd0/0xd0
[ 370.796576] __driver_attach_async_helper+0x1d/0xd0
[ 370.797318] ? driver_probe_device+0xd0/0xd0
[ 370.797957] async_schedule_node_domain+0xa5/0xc0
[ 370.798652] async_schedule_node+0x19/0x30
[ 370.799243] __driver_attach+0x246/0x290
[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0
[ 370.800548] bus_for_each_dev+0x9d/0x130
[ 370.801132] driver_attach+0x22/0x30
[ 370.801666] bus_add_driver+0x290/0x340
[ 370.802246] driver_register+0x88/0x140
[ 370.802817] ? virtio_scsi_init+0x116/0x116
[ 370.803425] scsi_register_driver+0x1a/0x30
[ 370.804057] init_sd+0x184/0x226
[ 370.804533] do_one_initcall+0x71/0x3a0
[ 370.805107] kernel_init_freeable+0x39a/0x43a
[ 370.805759] ? rest_init+0x150/0x150
[ 370.806283] kernel_init+0x26/0x230
[ 370.806799] ret_from_fork+0x1f/0x30
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable()
If 'ep' is NULL, result of ep_to_cdns3_ep(ep) is invalid pointer
and its dereference with priv_ep->cdns3_dev may cause panic.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci_plat_remove: avoid NULL dereference
Since commit 4736ebd7fcaff1eb8481c140ba494962847d6e0a ("usb: host:
xhci-plat: omit shared hcd if either root hub has no ports")
xhci->shared_hcd can be NULL, which causes the following Oops
on reboot:
[ 710.124450] systemd-shutdown[1]: Rebooting.
[ 710.298861] xhci-hcd xhci-hcd.2.auto: remove, state 4
[ 710.304217] usb usb3: USB disconnect, device number 1
[ 710.317441] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered
[ 710.323280] xhci-hcd xhci-hcd.2.auto: remove, state 1
[ 710.328401] usb usb2: USB disconnect, device number 1
[ 710.333515] usb 2-3: USB disconnect, device number 2
[ 710.467649] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
[ 710.475450] Unable to handle kernel NULL pointer dereference at virtual address 00000000000003b8
[ 710.484425] Mem abort info:
[ 710.487265] ESR = 0x0000000096000004
[ 710.491060] EC = 0x25: DABT (current EL), IL = 32 bits
[ 710.496427] SET = 0, FnV = 0
[ 710.499525] EA = 0, S1PTW = 0
[ 710.502716] FSC = 0x04: level 0 translation fault
[ 710.507648] Data abort info:
[ 710.510577] ISV = 0, ISS = 0x00000004
[ 710.514462] CM = 0, WnR = 0
[ 710.517480] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b0050000
[ 710.523976] [00000000000003b8] pgd=0000000000000000, p4d=0000000000000000
[ 710.530961] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 710.536551] Modules linked in: rfkill input_leds snd_soc_simple_card snd_soc_simple_card_utils snd_soc_nau8822 designware_i2s snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine arm_ccn panfrost ac97_bus gpu_sched snd_pcm at24 fuse configfs sdhci_of_dwcmshc sdhci_pltfm sdhci nvme led_class mmc_core nvme_core bt1_pvt polynomial tp_serio snd_seq_midi snd_seq_midi_event snd_seq snd_timer snd_rawmidi snd_seq_device snd soundcore efivarfs ipv6
[ 710.575286] CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc7-00043-gfd8619f4fd54 #1
[ 710.583822] Hardware name: T-Platforms TF307-MB/BM1BM1-A, BIOS 5.6 07/06/2022
[ 710.590972] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 710.597949] pc : usb_remove_hcd+0x34/0x1e4
[ 710.602067] lr : xhci_plat_remove+0x74/0x140
[ 710.606351] sp : ffff800009f3b7c0
[ 710.609674] x29: ffff800009f3b7c0 x28: ffff000800960040 x27: 0000000000000000
[ 710.616833] x26: ffff800008dc22a0 x25: 0000000000000000 x24: 0000000000000000
[ 710.623992] x23: 0000000000000000 x22: ffff000805465810 x21: ffff000805465800
[ 710.631149] x20: ffff000800f80000 x19: 0000000000000000 x18: ffffffffffffffff
[ 710.638307] x17: ffff000805096000 x16: ffff00080633b800 x15: ffff000806537a1c
[ 710.645465] x14: 0000000000000001 x13: 0000000000000000 x12: ffff00080378d6f0
[ 710.652621] x11: ffff00080041a900 x10: ffff800009b204e8 x9 : ffff8000088abaa4
[ 710.659779] x8 : ffff000800960040 x7 : ffff800009409000 x6 : 0000000000000001
[ 710.666936] x5 : ffff800009241000 x4 : ffff800009241440 x3 : 0000000000000000
[ 710.674094] x2 : ffff000800960040 x1 : ffff000800960040 x0 : 0000000000000000
[ 710.681251] Call trace:
[ 710.683704] usb_remove_hcd+0x34/0x1e4
[ 710.687467] xhci_plat_remove+0x74/0x140
[ 710.691400] platform_remove+0x34/0x70
[ 710.695165] device_remove+0x54/0x90
[ 710.698753] device_release_driver_internal+0x200/0x270
[ 710.703992] device_release_driver+0x24/0x30
[ 710.708273] bus_remove_device+0xe0/0x16c
[ 710.712293] device_del+0x178/0x390
[ 710.715797] platform_device_del.part.0+0x24/0x90
[ 710.720514] platform_device_unregister+0x30/0x50
[ 710.725232] dwc3_host_exit+0x20/0x30
[ 710.728907] dwc3_remove+0x174/0x1b0
[ 710.732494] platform_remove+0x34/0x70
[ 710.736254] device_remove+0x54/0x90
[ 710.739840] device_release_driver_internal+0x200/0x270
[ 710.745078] device_release_driver+0x24/0x30
[ 710.749359] bus_remove_device+0xe0/0x16c
[ 710.753380] device_del+0x178/0x390
[ 710.756881] platform_device_del.part
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: fix potential memory leak in setup_base_ctxt()
setup_base_ctxt() allocates a memory chunk for uctxt->groups with
hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups
is not released, which will lead to a memory leak.
We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups()
when init_user_ctxt() fails.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup
The function rxe_create_qp calls rxe_qp_from_init. If some error
occurs, the error handler of function rxe_qp_from_init will set
both scq and rcq to NULL.
Then rxe_create_qp calls rxe_put to handle qp. In the end,
rxe_qp_do_cleanup is called by rxe_put. rxe_qp_do_cleanup directly
accesses scq and rcq before checking them. This will cause
null-ptr-deref error.
The call graph is as below:
rxe_create_qp {
...
rxe_qp_from_init {
...
err1:
...
qp->rcq = NULL; <---rcq is set to NULL
qp->scq = NULL; <---scq is set to NULL
...
}
qp_init:
rxe_put{
...
rxe_qp_do_cleanup {
...
atomic_dec(&qp->scq->num_wq); <--- scq is accessed
...
atomic_dec(&qp->rcq->num_wq); <--- rcq is accessed
}
}
CVSS Score
5.5
EPSS Score
0.0
Published
2025-06-18