| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
HID: synchronize input before cleaning up a failed probe
hid_device_io_start() allows reports to run concurrently with probe. If
the probe subsequently fails, __hid_device_probe() releases driver
resources and clears hdev->driver without first excluding those report
callbacks.
For example, a report may enter hidraw_report_event() while the failure
path frees the associated hidraw object, leading to a use-after-free when
the report takes the object's list lock.
Stop input before performing failed-probe cleanup. This reacquires
driver_input_lock and waits for any report callback already in progress. |
| Use after free in Microsoft Edge (Chromium-based) allows an unauthorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
liveupdate: Remember FLB retrieve() status
LUO keeps track of successful retrieve attempts on an FLB. It does so
to avoid multiple retrievals of the same FLB. Multiple retrievals cause
problems because once the FLB is retrieved, the serialized data
structures are likely freed and the FLB is likely in a very different
state from what the code expects.
All this works well when retrieve succeeds. When it fails,
luo_flb_retrieve_one() returns the error immediately, without ever
storing anywhere that a retrieve was attempted or what its error code
was. If the user attempts to retrieve another file registered with the
same FLB, LUO will attempt to call the FLB's retrieve() callback again.
The retry is problematic for much of the same reasons listed above. The
FLB is likely in a very different state than what the retrieve logic
normally expects (e.g. some KHO pages may have already been restored and
freed).
There is no sane way of attempting the retrieve again. Remember the
error retrieve returned and directly return it on a retry.
This is done by changing the retrieved bool to a retrieve_status
integer. A value of 0 means retrieve was never attempted, a positive
value means it succeeded, and a negative value means it failed and the
error code is the value.
This is similar to commit f85b1c6af5bc ("liveupdate: luo_file: remember
retrieve() status") which did the same for LUO files. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: do not queue completed sysfs fallback requests
fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to
pending_fw_head. device_add() publishes the fallback loading interface, so
a userspace helper which discovers the device by scanning sysfs can write 0
to the loading attribute and complete the request before it is queued as
pending.
In that interleaving firmware_loading_store() calls fw_state_done() while
pending_list still points to itself, so it cannot remove an entry from
pending_fw_head. The subsequent unconditional list_add() then queues an
already-completed fw_priv. Once the request is released, pending_fw_head
can retain a pointer to freed memory and the next fallback request can
fault while validating the list.
Only in-flight fallback requests need suspend or reboot abort handling. If
the request is already DONE after device_add(), return success from the
fallback path without sending another uevent, waiting again, or queueing it
as pending. This preserves the invariant that pending_fw_head contains only
active fallback requests. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/omap: dsi: Do not copy isr table
To be able to unregister stuff from isrs, the corresponding table was
copied. Nobody seems to unregister stuff that way, so it does not help.
But there are stack-allocated objects passed to these isrs giving chances
of UAF of these objects if irqs are unregistered while they are handled,
so better do not copy that table. |
| In the Linux kernel, the following vulnerability has been resolved:
rapidio: clear mport->net when rio_add_net() fails
rio_alloc_net() stores the newly allocated rio_net in mport->net before
rio_scan_alloc_net() registers the device.
If rio_add_net() fails, rio_scan_alloc_net() drops the device reference
with put_device(), which releases the rio_net through the device release
callback. However, mport->net is left pointing at the freed object.
A later mport unregister path can then dereference the dangling mport->net
pointer and may try to free the same rio_net again.
Clear mport->net in the rio_add_net() failure path, matching the cleanup
done for the destID table allocation failure path. |
| In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: skip dying blkg in blkcg_activate_policy()
When switching IO schedulers on a block device, blkcg_activate_policy()
can race with concurrent blkcg deletion, leading to a use-after-free in
rcu_accelerate_cbs.
T1: T2:
blkg_destroy
kill(&blkg->refcnt) // blkg->refcnt=1->0
blkg_release // call_rcu(__blkg_release)
...
blkg_free_workfn
->pd_free_fn(pd)
elv_iosched_store
elevator_switch
...
iterate blkg list
blkg_get(blkg) // blkg->refcnt=0->1
list_del_init(&blkg->q_node)
blkg_put(pinned_blkg) // blkg->refcnt=1->0
blkg_release // call_rcu again
rcu_accelerate_cbs // uaf
Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting
a reference to the blkg. This is the same check used in blkg_destroy()
to detect if a blkg has already been destroyed. If the blkg is already
unhashed, skip processing it since it's being destroyed. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix potential UAF in bpf_netns_link_update_prog
In bpf_netns_link_update_prog, the checks for old_prog and prog type
are currently performed locklessly before acquiring netns_bpf_mutex.
This creates a race condition that can lead to a UAF issue.
If two threads concurrently execute BPF_LINK_UPDATE on the same netns
link, the following execution path can trigger a UAF:
CPU0 CPU1
bpf_netns_link_update_prog
if (old_prog && old_prog != link->prog)
return -EPERM;
bpf_netns_link_update_prog
if (old_prog && old_prog != link->prog)
...
old_prog = xchg(&link->prog, new_prog);
bpf_prog_put(old_prog);
if (new_prog->type != link->prog->type) <-- trigger UAF
Fix this by moving the old_prog and prog->type checks inside the
netns_bpf_mutex critical section. Meanwhile, use guard() to simplify
lock management and avoid all the goto jumping. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_ec_debugfs: Unregister panic notifier
cros_ec_debugfs_probe() registers notifier_panic with the EC panic
notifier chain. The remove path tears down debugfs and the console log,
but leaves the notifier registered. A later panic notification can call
back into the removed instance and queue work that accesses released
data.
Unregister the panic notifier before tearing down the debugfs and
console log state.
This issue was found by a static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
remoteproc: Prevent crash handling to race with rproc_del()
There's no synchronization between rproc_crash_handler_work() and
rproc_del(), as such it's possible for a driver to be removed while
crash-handler work is scheduled, or even executing - resulting in
use-after-free issues.
To avoid this the scheduled work need to be cancelled and synchronized
against before the removal proceeds.
In order to ensure that this doesn't race with the reporting, and
thereby scheduling new work, a "deleting" flag is introduced. This is
similar to the RPROC_DELETE state that was introduced to ensure that
"start" didn't race with rproc_del(), but the existing mechanism can not
be used as it's valid to call rproc_report_crash() in atomic context -
and the "state" is protected by a mutex.
In the event that work is cancelled the pm_stay_awake() is left
unbalanced and need to be unrolled.
The blocking and cancelling of crash-handler work prior to the actual
rproc_shutdown() call does have the explicit side-effect that crashes
resulting from the shutdown process will not enter the crash-handling
path, and as such will not generate devcoredumps etc. Due to the
existing mutual exclusion between these code paths there's no concrete
reduction in functionality, but further work would be needed to handle
this case. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix potential use after free in counter_release()
When accessing a counter via the netlink path the only synchronization
mechanism for the said counter is rdma_restrack_get().
Currently, rdma_restrack_del() is invoked at the end of
counter_release(), which is too late, since by that point
vendor-specific resources associated with the counter might already be
freed. This can leave a short window where the counter remains
accessible through restrack, leading to a potential use-after-free.
Fix this by moving the rdma_restrack_del() call to be before the
freeing of the vendor-specific resources, ensuring that the counter is
removed from restrack before its internal resources are released.
This guarantees that no new users hold references to a counter that is
in the process of destruction. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: sc2731_charger: cancel work on remove
The USB notifier and initial charger detection can schedule info->work.
The remove path unregisters the notifier, but does not cancel queued or
running work before the devm-allocated driver data is released.
Set the platform drvdata used by remove, then cancel the work after
unregistering the notifier.
This issue was found by a static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/erdma: Fix CEQ tasklet use-after-free on removal
Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls
erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring
through get_next_valid_eqe() and updates eq->dbrec through notify_eq().
erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ.
free_irq() prevents another hard IRQ and waits for an in-flight handler,
but it does not drain a tasklet that the handler already scheduled. The
tasklet can therefore access eq->qbuf or eq->dbrec after
erdma_eq_destroy() frees them.
Clearing ceq_cb->ready does not synchronize with a tasklet that already
passed the check at the start of erdma_ceq_completion_handler().
Kill the tasklet after free_irq(), when no handler can schedule it again,
and before erdma_ceq_uninit_one() releases the EQ buffers. |
| 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:
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. |
