| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: isp1704_charger: cancel work on remove
The USB notifier and initial VBUS detection can schedule isp->work. The
remove path unregisters the notifier and power supply, but does not wait
for queued or running work before tearing down the power supply state.
Cancel the work after unregistering the notifier. Do this before
unregistering the power supply.
This issue was found by a static analysis tool. |
| 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:
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:
bpf: Fix potential UAF when reading bpf link info
In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is
accessed without holding any locks. If the prog is concurrently replaced
via bpf_link_update, the old prog can be freed, leading to a potential
UAF issue.
Fix this by accessing link->prog under RCU protection to safely fetch
the pointer and guarantee its lifetime while reading its fields. |
| In the Linux kernel, the following vulnerability has been resolved:
lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone
dmirror_fault() is called from the dmirror_read() and dmirror_write()
retry loops after dmirror_do_read() or dmirror_do_write() finds a missing
device page table entry.
If the mirrored mm has already exited, mmget_not_zero() fails. The
current code returns 0 in that case, which tells the caller that faulting
succeeded even though no page was faulted and no device page table entry
was installed. The caller then retries the same address, hits -ENOENT
again, and can loop forever without making progress.
Return -EFAULT instead, so the ioctl fails when the mirrored mm is no
longer faultable. |
| In the Linux kernel, the following vulnerability has been resolved:
md/bitmap: resume array on backlog_store() error path
backlog_store() suspends the array before checking whether a write-mostly
device exists. If no such device exists, the error path only unlocks
reconfig_mutex and leaves the array suspended, blocking subsequent I/O.
Use mddev_unlock_and_resume() to release both states. |
| In the Linux kernel, the following vulnerability has been resolved:
md: scope memalloc_noio to allocation critical sections
Storing a memalloc_noio_save() token in mddev->noio_flags lets one task
save the token and another task restore it. With concurrent suspend sysfs
writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in
that scope, and later task B can restore A's saved token.
Avoid tying the token lifetime to mddev. Keep mddev_suspend() and
mddev_resume() only responsible for array suspension, and enter
PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array
has been suspended. Restore the token before resuming the array.
A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent
workers and checks each worker's /proc/self/stat flags before and after the
sysfs write. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/dma: Check atomic pool allocation result directly
The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(),
which returns the allocated page and fills cpu_addr only on success.
Do not rely on cpu_addr to detect allocation failure in this path. Check
the returned page directly before using it for the IOMMU mapping. |
| In the Linux kernel, the following vulnerability has been resolved:
swiotlb: Preserve allocation virtual address for dynamic pools
swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted
pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the
atomic pool is backed by remapped virtual addresses, which are not the same
as the direct-map addresses returned by phys_to_virt().
swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address
from the physical start address. For atomic-pool backed allocations this
stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes
that address to dma_free_from_pool(), which will fail to recognize the
chunk
Pass the virtual address returned by the allocation path into
swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This
keeps the pool free path using the same virtual address as the allocator. |
| In the Linux kernel, the following vulnerability has been resolved:
i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices
On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count
of addresses left unassigned) equals master->maxdevs.
The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1,
which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD
server:
UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy)
Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026
Call Trace:
<TASK>
dump_stack_lvl+0x5d/0x80
ubsan_epilogue+0x5/0x2b
__ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab
dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master]
i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c]
Skip the mask when no new device was assigned. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid1: create serial pool adding rdev to array with serialize_policy=1
The following bug has been observed with kernel 7.1.3 after adding a new
rdev to an existing RAID1 array with serialize_policy enabled:
Oops: 0002 [#1]
CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default
RIP: _raw_spin_lock_irqsave+0x27/0x50
CR2: 0000000000004960
Call Trace:
wait_for_serialization+0xb9/0x260 [raid1]
raid1_make_request+0x762/0xaff [raid1]
md_handle_request+0x1c9/0x2e0 [md_mod]
The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY
is set, and wait_for_serialization assumes that rdev->serial is
initialized. Normally this will be the case for arrays that have
the serialize_policy sysfs attribute set to 1.
But when a new rdev is added to an existing array in bind_rdev_to_array(),
the condition at mddev_create_serial_pool() causes creation of rdev->serial
to be skipped. Fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
iomap: release the folio batch on iomap callback failures
A sashiko review of an unrelated patch points out that the folio
batch mechanism used for iomap zero range fails to release the batch
in a couple error scenarios. If either calls to ->iomap_end() or
->iomap_begin() fail, the direct return paths bypass the batch
cleanup.
The ->iomap_end() case is not a practical issue at the moment
because there is no user of the mechanism that returns an error from
this path. The ->iomap_begin() case is theoretically possible
because XFS can invoke the fill helper and error out at various
points thereafter. This subtly complicates things because XFS does
not transfer iomap_flags to the iomap data structure in the error
path.
To deal with both of these issues, first make sure to invoke the
cleanup helper in the error path for either fs callback. Second,
update the helper to clear the flag unconditionally and release the
batch so long as it is populated. This more clearly delineates the
purpose of the flag to control the I/O path and not necessarily the
status of the fbatch, so add a comment around this as well. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: sgi-gru: remove interrupt-context page-table walks
The GRU TLB miss handler walks a process's page tables without holding
page-table locks or a reference to the mapped page. It also uses a kernel
page-table accessor on user page tables and supports only PMD-level large
mappings on x86-64.
Remove the direct walker. Send interrupt faults directly to user polling
mode so the existing call-OS fallback retries them in process context.
Remove the mmap-lock failure statistic that can no longer be incremented. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length
The MPDU length in the rx descriptor comes from the hardware. In
monitor mode with the fcsfail filter enabled, the hardware passes up
corrupted frames, and a corrupted frame can report a length larger
than the received buffer. The bounds check correctly discards such
frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage
frame taints the kernel, and panics it on the first such frame when
panic_on_warn is set.
Drop the WARN and discard the frame silently, matching what
commit c2d4c8723dbf ("mt76x2: remove some harmless WARN_ONs in tx
status and rx path") did for the neighboring rx and tx status paths.
Observed immediately on rx with an MT7612U in fcsfail monitor mode
on a busy channel. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: fix handling channel context with different bands in mt76_switch_vif_chanctx()
When performing channel switches on different radios within a short
timeframe, channel contexts with different bands can be carried for
each struct ieee80211_vif_chanctx_switch.
Rework mt76_switch_vif_chanctx() to properly handle this scenario. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete
A use-after-free issue occurs in mt76_rx_poll_complete due to a race
condition. The STA has already been removed, but the rx_status still
had a pointer to the wcid in the STA.
Set the links' wcid pointers to be NULL for a MLD in
mt7925_sta_pre_rcu_remove()
BUG: KASAN: invalid-access in mt76_rx_poll_complete+0x280/0x470
Call trace:
dump_backtrace+0xec/0x128
show_stack+0x18/0x28
dump_stack_lvl+0x40/0xc8
print_report+0x1b8/0x710
kasan_report+0xe0/0x144
do_bad_area+0x120/0x260
do_tag_check_fault+0x20/0x34
do_mem_abort+0x54/0xa8
el1_abort+0x3c/0x5c
el1h_64_sync_handler+0x40/0xcc
el1h_64_sync+0x7c/0x80
mt76_rx_poll_complete+0x280/0x470
mt76_dma_rx_poll+0x114/0x51c
mt792x_poll_rx+0x60/0xf8
napi_threaded_poll_loop+0xe0/0x450
napi_threaded_poll+0x80/0x9c
kthread+0x11c/0x158
ret_from_fork+0x10/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash
When an AER error occurs and the bus is hung, the register reads return
0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in
an invalid memory access when accessing q->desc[] or q->entry[].
Unable to handle kernel paging request at virtual address
ffffffc01099eac0
pc : mt76_dma_add_buf+0x124/0x188 [mt76]
lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76]
sp : ffffffc016d9bbf0
x29: ffffffc016d9bc10 x28: 0000000000000000
x27: 0000000000000000 x26: ffffffb7855e50b8
x25: ffffffb80d04f000 x24: 0000000000000000
x23: 0000000000000ec0 x22: ffffffb796803648
x21: ffffffb796801f80 x20: ffffffb7968035f8
x19: 0000000000000ec0 x18: 0000000000000000
x17: 000000004ec00000 x16: 000000000ec00000
x15: ffffffc01099eac0 x14: 000000004ec00000
x13: 00000000ffc5a000 x12: ffffffc016d9bc32
x11: 00000000ffffffff x10: 0000000000000002
x9 : 0000000000000000 x8 : 000000000000b4ac
x7 : 0000000000000a20 x6 : ffffffb6c1806400
x5 : 0000000000000000 x4 : ffffffb80d04f000
x3 : 0000000000000000 x2 : 0000000000000001
x1 : 000000000ec04000 x0 : ffffffb7968035f8
Call trace:
mt76_dma_add_buf+0x124/0x188 [mt76 (HASH:1029 4)]
mt76_dma_rx_reset+0xe8/0xfc [mt76 (HASH:1029 4)]
mt7921_wpdma_reset+0x188/0x1b0 [mt7921e (HASH:ee48 5)]
mt7921e_mac_reset+0x128/0x418 [mt7921e (HASH:ee48 5)]
mt7921_mac_reset_work+0xac/0x1a8 [mt7921_common (HASH:f721 6)]
process_one_work+0x188/0x514
worker_thread+0x12c/0x300
kthread+0x140/0x1fc
ret_from_fork+0x10/0x30
Fix the invalid memory access by validating the DMA index read from the
hardware before it is used as a queue index. An out-of-range value, such
as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can
no longer corrupt q->head or q->tail. In addition, check the bus_hung flag
in mt7921_mac_reset_work() before attempting the reset sequence, reject MCU
messages while the bus is hung, and install no-op bus operations when an
unrecoverable AER error is detected, preventing further invalid hardware
accesses.
Due to hardware limitations - such as the lack of a connected hardware
reset pin or the absence of host re-probe functionality - affected Wi-Fi
devices may not fully recover to a normal operational state after
certain errors, even with AER enabled. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt792x: Fix memory leak in SDIO TX path
When tx_prepare_skb() returns an error in the SDIO TX path, the
skb is not freed, leading to a memory leak. This can occur when
zero-length frames (such as WNM NULL frames) are dropped to prevent
potential hardware TX hangs.
Fix this by properly releasing the skb with ieee80211_tx_status_ext()
when tx_prepare_skb() fails. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: fix RX data queuing of RRO 3.0
For RRO 3.0, RX data released from a RRO data queue should be put to
the indicator queue. The frames are processed and completed in the
context of the indicator queue NAPI, which only polls skbs queued on
the MT_RXQ_RRO_IND list; frames queued under the data queue id are
left sitting on that list until the data queue NAPI happens to run,
stalling and reordering RX data. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP
Problem:
MCU command timeout while the firmware state is normal, and the
firmware keeps showing the error log "ERROR!! NO PAUSE...".
Root cause:
If the MLD_ID field in the TXD is neither the primary link id nor the
secondary link id, it may lead to a firmware busy loop when the third
link is in power saving mode.
Remap frames directed to a third link to the primary link wcid. Since
TX status events and txfree completions carry the wcid the firmware
saw, use the remapped wcid for packet id tracking and non-AQL packet
accounting as well, while the frame keeps its original link context
for addressing, band and OMAC selection. |
