| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root
acpi_pci_root_add() assigns the freshly allocated root to
device->driver_data before dmar_device_add() and pci_acpi_scan_root().
Both failure paths reach the end: label where root is kfree()'d, but
only the pci_acpi_scan_root() path clears driver_data first.
When dmar_device_add() fails during a hot-add, root is freed while
device->driver_data still points at it. The ACPI core does not clear
driver_data on attach failure, so a later acpi_pci_find_root() call may
dereference this dangling pointer.
acpi_pci_root_remove() has the same problem: it frees root without
clearing device->driver_data, leaving a dangling pointer behind after
the root bridge is removed.
Move the NULL assignment to the shared end: label so every error path in
acpi_pci_root_add() clears driver_data before freeing root, and clear it
in acpi_pci_root_remove() as well, so the object is never left reachable
through driver_data after being freed. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/adreno: fix use after free on error path in a6xx_gpu_init()
The a6xx_destroy() function frees "a6xx_gpu" and so "adreno_gpu" points
to freed memory. Preserve the error code before freeing the memory to
avoid a use after free.
Patchwork: https://patchwork.freedesktop.org/patch/732275/ |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix UAF when probe runs concurrent to dyn ID removal
Dynamic IDs are only guaranteed to be valid when dynids.lock is held,
as remove_id_store() can free the node. Thus, make a copy in
pci_match_device(). Also, clarify that the id parameter is only valid
during probe. |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip
The gpio_chip is allocated with device-managed memory but registered with
the non-managed gpiochip_add_data(). This was harmless while the drivers
were built-in, but once they can be built as modules and unbound/rmmod'd,
devm frees the gpio_chip's memory while it is still registered, causing a
use-after-free.
Register it with devm_gpiochip_add_data() so it shares the same
device-managed lifecycle, which also lets the manual gpiochip_remove()
error paths go away. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: Fix skb double-free in xfrm_dev_direct_output()
A return value other than 1 from local_out() means that the skb has been
consumed or its ownership was transferred. xfrm_dev_direct_output()
nevertheless frees the skb on this path, causing a double-free when
netfilter drops the packet and invalidating any other owner.
Return the local_out() result directly, matching the ownership handling
in xfrm_output_resume(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: dw_dp: Release core resources
Core resources such as the DisplayPort AUX channel get initialized and
registered during dw_dp_bind(), but are never unregistered, which may
lead to memory leaks and/or use-after-free:
[ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0
[ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658
[ 224.662612]
[ 224.662752] CPU: 7 UID: 0 PID: 658 Comm: modprobe Not tainted 7.0.0-rc2-next-20260305 #14 PREEMPT
[ 224.662759] Hardware name: Radxa ROCK 5B (DT)
[ 224.662762] Call trace:
[ 224.662764] show_stack+0x20/0x38 (C)
[ 224.662772] dump_stack_lvl+0x6c/0x98
[ 224.662777] print_report+0x160/0x4b8
[ 224.662783] kasan_report+0xb4/0xe0
[ 224.662790] __asan_report_load8_noabort+0x20/0x30
[ 224.662796] device_is_dependent+0xe0/0x2b0
[ 224.662802] device_is_dependent+0x108/0x2b0
[ 224.662808] device_link_add+0x1f8/0x10b0
[ 224.662813] devm_of_phy_get_by_index+0x120/0x200
[ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp]
[ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm]
[ 224.662864] component_bind_all+0x3a8/0x720
[ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm]
[ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838
[ 224.662904] component_master_add_with_match+0x1f4/0x230
[ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm]
[ 224.662939] platform_probe+0xe8/0x168
[ 224.662945] really_probe+0x340/0x828
[ 224.662950] __driver_probe_device+0x2e0/0x350
[ 224.662954] driver_probe_device+0x80/0x140
[ 224.662959] __driver_attach+0x398/0x460
[ 224.662964] bus_for_each_dev+0xe0/0x198
[ 224.662968] driver_attach+0x50/0x68
[ 224.662972] bus_add_driver+0x2a0/0x4c0
[ 224.662977] driver_register+0x294/0x360
[ 224.662982] __platform_driver_register+0x7c/0x98
[ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm]
Since a previous commit exported dw_dp_unbind() function in DW DP core
library to take care of the necessary cleanup, use this in the
component's unbind() callback, as well as in its bind() error path. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Fix use-after-free in find_pos_and_ways() error path
The error path releases its reference to a switch decoder before
logging an error that includes the decoder name. If the released
reference is the last one, the decoder can be freed before the error
message accesses its name.
Drop the reference after the error is reported. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Roll back partial protocol table registration
scmi_protocol_table_register() can leave earlier requests registered when
a later entry in the same ID table fails. Each request retains a pointer
to the driver's ID table, so a failed module load can leave a dangling
pointer after the module storage is released.
Unrequest only the successfully registered prefix, in reverse order,
before returning the failure. Leave the failed entry and the remaining
entries untouched because matching requests can be owned by another
driver. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: validate readdir offset before accessing dirent
A corrupted directory can trigger the following KASAN report when
ext4_readdir() resumes from an invalid position:
BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820
Read of size 2 at addr ffff88810a646000 by task repro_linear/509
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_report+0xd0/0x630
kasan_report+0xce/0x100
__ext4_check_dir_entry+0x5ef/0x820
ext4_readdir+0xcde/0x2b70
iterate_dir+0x1a1/0x520
__x64_sys_getdents64+0x12b/0x220
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
KASAN reports use-after-free because the out-of-bounds access lands in an
adjacent freed page. The directory buffer itself is still referenced.
ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir()
rescans directory entries from the start of the block. The rescan checks
only the lower bound of rec_len before advancing. A corrupted rec_len can
therefore place the offset where the block has insufficient space for a
complete directory entry. The rescan itself may dereference that truncated
entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter
reads de->rec_len before validating the range. For example:
block offset 0 4092 4096
|---- de1.rec_len = 4092 -----|----|
de2.inode
| de2.rec_len
^ OOB, reported as UAF
de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in
the block, but its rec_len starts at offset 4096 and crosses the boundary.
The minimum safe length is inode-dependent. Encrypted and casefolded
directory entries need eight additional hash bytes, while a valid metadata
checksum tail is only 12 bytes.
Cache the metadata checksum feature state and derive the minimum directory
entry length from the on-disk format. Use it to bound both the rescan and
the offset passed to the main loop. Report an offset in a truncated block
tail and skip the remainder of the block, while continuing to accept an
offset exactly at the block boundary. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Unregister device notifier before IDR teardown
The requested-devices notifier looks up protocol fwnodes from the
active_protocols IDR. During remove, unregister the notifier before
releasing and destroying active_protocols so no notifier callback can race
with the IDR teardown.
Keep the bus notifier registered until after the protocol state is torn
down, matching the existing remove ordering for SCMI bus users. |
| In the Linux kernel, the following vulnerability has been resolved:
dax/fsdev: clear pgmap ops and owner on unbind
fsdev_dax_probe() sets pgmap->ops = &fsdev_pagemap_ops and
pgmap->owner = dev_dax, but nothing ever clears them. For a dynamic
device the pgmap is devm-allocated and freed on unbind, so this is
harmless. For a static device the pgmap is the shared, long-lived one
owned by the dax bus (kill_dev_dax() only NULLs dev_dax->pgmap for the
non-static case), and device.c's probe sets only pgmap->type, never
clearing ops/owner.
So after fsdev unbinds a static device the stale fsdev_pagemap_ops
survives on the shared pgmap. If the device is then rebound to
device_dax (MEMORY_DEVICE_GENERIC, which installs no ->memory_failure),
or the fsdev_dax module is unloaded, a subsequent memory_failure on that
pgmap dispatches through the stale -- and possibly freed -- handler.
Register a devm action that clears pgmap->ops and pgmap->owner on unbind,
symmetric with setting them at probe, so the pgmap carries no fsdev state
once fsdev is detached. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Quiesce notifications before teardown
scmi_notification_exit() clears and releases the notification instance,
but transport callbacks can still deliver incoming notifications until
the TX/RX channels are freed. During remove, an RX interrupt in that
window can enter scmi_notify() while notification state is being torn
down and then dereference freed memory. The same ordering exists on the
probe error path after notification initialization.
The notification late-init worker has a separate lifetime issue: protocol
event registration queues ni->init_work on the system workqueue, so
destroying ni->notify_wq does not drain that work. If the devres group is
released while init_work is still pending or running, the late-init worker
can dereference the freed notification instance.
Quiesce the notification core before TX/RX channels are torn down, then
clean up the channels before releasing the notification core resources.
Use disable_work_sync() so future late-init queueing is rejected and any
already queued or running late-init work has completed before channel
teardown starts. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollback
ath12k_mac_vdev_create() for an AP vdev creates the bss self-peer via
ath12k_peer_create(), which finishes by calling
ath12k_dp_link_peer_assign() to publish the dp_link_peer in the
dp_hw->dp_peers[peerid_index] RCU table, in the dp_peer's
link_peers[] array, and in the per-addr rhashtable.
If a step after ath12k_peer_create() fails the function jumps to
err_peer_del, which open-codes a WMI peer_delete and waits for the
unmap / delete_resp events. The wait_for_peer_delete_done() path
relies on ath12k_dp_link_peer_unmap_event() freeing the dp_link_peer
when the unmap arrives, but err_peer_del never calls
ath12k_dp_link_peer_unassign() first. The published references in
the dp_hw RCU table, dp_peer->link_peers[] and the rhashtable are
left pointing at the dp_link_peer that unmap_event then frees,
producing dangling pointers and use-after-free on subsequent
lookups.
Replace the open-coded sequence with a call to ath12k_peer_delete(),
which already does ath12k_dp_link_peer_unassign() before sending the
WMI command. This drops the published references before the
dp_link_peer is freed, in the same order as the normal teardown path
in ath12k_mac_remove_link_interface().
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 |
| In the Linux kernel, the following vulnerability has been resolved:
fs/resctrl: Fix UAF from worker threads when domains are removed
The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters
and may sleep while doing so. They are scheduled via delayed_work embedded in
struct rdt_l3_mon_domain. Architecture allocates and frees these domains from
CPU hotplug callbacks under cpus_write_lock(), and the workers acquire
cpus_read_lock() to keep the domain alive across their access.
A use-after-free can occur when a worker is blocked waiting for
cpus_read_lock() while the hotplug core holds cpus_write_lock(): the
architecture frees the rdt_l3_mon_domain that contains the worker's
work_struct. When the worker unblocks, the container_of() it performs on the
embedded work pointer dereferences freed memory.
Drop cpus_read_lock() from the workers and instead drain pending and in-flight
work synchronously before the architecture can free the domain. Since
architecture offlines the domain under cpus_write_lock() after it has been
unlinked from the RCU list and a grace period has elapsed, no new work can be
scheduled. The cancel only needs to wait out existing work. Drop
rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that
a worker waiting on the mutex can complete before re-pinning the work on
a different CPU.
When offlining a CPU the architecture may iterate over resources in any order.
For example, the MBA control domain may be offlined before or after
a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers
no matter what order the architecture offlines the domains. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rvt: Return NULL after port allocation failure
rvt_alloc_device() deallocates the IB device when its port array cannot
be allocated but then returns the pointer to the released allocation.
Callers treat any non-NULL value as valid and dereference it, resulting
in a use-after-free.
Return NULL immediately after deallocation so callers can propagate the
allocation failure. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Add refcounting to user ring MRs
Prevent userspace from deregistering the MRs that back QP/CQ/SRQ rings
by bumping the MR's refcount upon association. |
| In the Linux kernel, the following vulnerability has been resolved:
leds: lp5860: Fix a potential double-unlock
In lp5860_device_init(), if lp5860_init_dt() fails, an already unlocked
mutex is unlocked another time.
Slightly rework how the lock is taken/released to avoid this potential
double unlock. |
| In the Linux kernel, the following vulnerability has been resolved:
esp: do not unref managed frag pages in esp_ssg_unref()
esp_ssg_unref() releases the page references held on the source
scatterlist after the AEAD operation completes. It calls
skb_page_unref() on every frag page for an out-of-place transform
(req->src != req->dst), and in the error path of esp_output_tail()
(already_unref == true) on the request's own scatterlist.
This is wrong when the skb carries managed frags
(SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf
and the skb does not hold a per-frag page reference; io_uring SEND_ZC
with a registered buffer attaches the bvec pages this way via
io_sg_from_iter(). The rest of the stack honours this invariant:
skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS
is set, and skb_zcopy_managed() is the guard used at the other unref
sites.
esp_ssg_unref() is missing that guard, so for a managed-frag skb it
drops a page reference the skb never acquired. This can underflow the
page reference count and free a page that is still in use.
Guard the function with skb_zcopy_managed() so both unref paths are
skipped for managed-frag skbs, matching skb_release_data(). |
| In the Linux kernel, the following vulnerability has been resolved:
crash_dump: release keyring reference at the correct time
restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user
keyring before restoring the saved dm-crypt keys.
The same keyring reference is then passed to add_key_to_keyring() for each
saved key, but add_key_to_keyring() drops that reference on every call.
This is only balanced when exactly one key is restored. With multiple
keys, the keyring reference is dropped too many times and may trigger a
refcount underflow or use-after-free.
When more than five keys are restored, a refcount underflow/use-after-free
warning can be triggered.
The early error paths after lookup_user_key() also return without dropping
the keyring reference.
Keep ownership of the keyring reference in
restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths,
and make add_key_to_keyring() only use the reference without consuming it. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Drain RCU callbacks during module teardown
devx_free_subscription() can remain queued after the last DevX event file
drops its module reference or an auxiliary driver detaches its devices.
mlx5_ib can then unload before the callback runs.
Registration error unwind has the same risk because driver registration
can attach existing devices before failing. Wait after all drivers have
stopped. |
