🚨 CVE-2026-80938
In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex

mt7615_suspend() acquired the mt76 mutex and then called
cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the
same mutex via mt7615_mutex_acquire() at the top of the worker, so if
mac_work is already running and blocked on the mutex, the suspend path
deadlocks waiting for the work it holds the mutex against.

Flush scan_work and mac_work before taking the mutex, matching the
suspend paths in mt7921 and mt7925. scan_work only takes the mt76
spinlock, but moving it keeps the sequence consistent. This also keeps
mac_work from running over an already suspended HIF, which the previous
split (async cancel under the lock, sync cancel after release) would
have allowed.

🎖@cveNotify

🚨 CVE-2026-80939
In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot

Since the hardware rfkill polling was introduced, arm64 platforms can
panic with an asynchronous SError during warm reboot:

SError Interrupt on CPU8, code 0x00000000be000011 -- SError
Workqueue: events_power_efficient rfkill_poll [rfkill]
rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci]
rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core]
rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core]
ieee80211_rfkill_poll+0x3c/0x70 [mac80211]
cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211]
rfkill_poll+0x30/0x88 [rfkill]
Kernel panic - not syncing: Asynchronous SError Interrupt

On the reboot path the kernel only runs device_shutdown(), which calls
each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI
driver had no .shutdown callback, so nothing stopped the rfkill polling
work while the platform was tearing the PCIe link down. Once the link
is gone, the next MMIO read from the poll handler targets a
non-responding device and is reported as a fatal asynchronous SError on
arm64.

Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which
sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB
RTW89_FLAG_UNPLUGGED pattern). When the flag is set,
rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the
chip after shutdown begins and the SError no longer occurs.

This does not call the full .remove path from .shutdown, to keep the
shutdown handler minimal and avoid running the non-idempotent teardown
twice.

🎖@cveNotify

🚨 CVE-2026-80940
In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: pci: fix resource leak on failed NAPI setup

rtw_pci_probe() allocates PCI resources through
rtw_pci_setup_resource() before it sets up NAPI. If
rtw_pci_napi_init() fails, the error path jumps straight to
err_pci_declaim and skips rtw_pci_destroy(), leaving the PCI
resources allocated by rtw_pci_setup_resource() behind.

Add a dedicated cleanup label for the NAPI setup failure path so probe
destroys the PCI resources.

The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing current
mainline kernels. The tool is still under development and is not yet
publicly available. Manual inspection confirms that the bug is still
present in v7.1-rc7.

An x86_64 allyesconfig build showed no new warnings. As we do not have a
suitable rtw88 PCI board to test with, no runtime testing was able to be
performed.

🎖@cveNotify

🚨 CVE-2026-80941
In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb()

The skb passed to the rtw_hci_tx_write() is expected to be freed when
the function fails, but the error path in rtw_txq_push_skb() does not
free the skb before returning. This can lead to a memory leak in
rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().

🎖@cveNotify

🚨 CVE-2026-80942
In the Linux kernel, the following vulnerability has been resolved:

wifi: rtlwifi: rtl8192du: Fix possible memory leak in rtl92du_init_sw_vars()

The memory allocated inside rtl92du_init_shared_data() is not freed in
any of the subsequent error paths in rtl92du_init_sw_vars().
Fix that by adding a call to rtl92du_deinit_shared_data() in the error
path.

🎖@cveNotify

🚨 CVE-2026-80943
In the Linux kernel, the following vulnerability has been resolved:

wifi: rtlwifi: rtl8192du: check QoS TID before indexing tids

rtl92du_tx_fill_desc() uses ieee80211_get_tid() to read the QoS TID
from the 802.11 header and then uses it as an index into
sta_entry->tids[]. ieee80211_get_tid() returns the low 4-bit QoS TID
value, so the result can be in the range 0..15.

rtlwifi only allocates MAX_TID_COUNT entries for sta_entry->tids[], and
MAX_TID_COUNT is 9. A QoS TID greater than 8 therefore indexes past the
aggregation state array. Keep the default RTL_AGG_STOP state for
out-of-range TIDs, matching rtl92cu_tx_fill_desc().

This issue was detected by our static analysis tool and confirmed by
manual audit. UBSAN validation for the same bug pattern reports an
array-index-out-of-bounds access with index 10 for type
'rtl_tid_data [9]'.

🎖@cveNotify

🚨 CVE-2026-80944
In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Detach sync cmd buffer on interrupted wait

mwifiex synchronous commands keep the caller-provided data buffer in
cmd_node->data_buf. Several callers pass stack-allocated objects there.

If wait_event_interruptible_timeout() is interrupted, the caller can
return and release that stack object while the firmware command is still
the current command. A late firmware response then reaches the normal
response handler, which can copy data through cmd_node->data_buf into the
stale stack address.

This fixes a stack corruption observed during repeated association and
disassociation cycles. The panic trace showed the command wait being
interrupted immediately before a bad pointer dereference:

cmd_wait_q terminated: -512
Unable to handle kernel paging request at virtual address 002c583837384662
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
...
Tainted: [M]=MACHINE_CHECK

The fault address decodes as little-endian ASCII:

0x002c583837384662 -> "bF878X,\0"

which is a fragment of the VERSION_EXT firmware string exposed as
debugfs "verext":

w8997o-V4, RF878X, FP92, 16.92.21.p153.7

The same runs also showed corrupted control data containing:

0x2400372e333531 -> "153.7\0$"

which is the tail of the same VERSION_EXT string. This points at a late
VERSION_EXT response writing through a stale stack-backed data_buf after
the interrupted wait returned.

After cancelling pending commands on an interrupted or timed-out wait,
detach the caller-owned data buffer from the still-current command. This
preserves the existing command cancellation behaviour while preventing a
late response from writing through a pointer whose lifetime ended with the
waiting caller.

Tested on an i.MX8MP board using an 88W8997.

🎖@cveNotify

🚨 CVE-2026-80945
In the Linux kernel, the following vulnerability has been resolved:

crypto: iaa - unmap dst before software fallback on decompress

On a hardware analytics error, decompress retries through the software
fallback, which writes req->dst with the CPU while it is still mapped
DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the
stale bounce buffer over req->dst, corrupting the result.

Unmap before the fallback runs. The async path unmaps inline; the sync
path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the
fallback after unmapping.

🎖@cveNotify

🚨 CVE-2026-80946
In the Linux kernel, the following vulnerability has been resolved:

fuse: copy request headers via a stack buffer for io-uring

The fuse-io-uring transport copies req->in.h out to the ring in
fuse_uring_copy_to_ring() and req->out.h back in fuse_uring_commit().
Both headers live inside the fuse_request slab object, whose cache
(fuse_req_cachep) is created without a usercopy whitelist, so copying
them directly to/from userspace trips CONFIG_HARDENED_USERCOPY and
panics:

usercopy: Kernel memory exposure attempt detected from SLUB object
'fuse_request' (offset 56, size 40)!
kernel BUG at mm/usercopy.c:102!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:usercopy_abort (mm/usercopy.c:90)
Call Trace:
__check_heap_object (mm/slub.c:8268)
__check_object_size (mm/usercopy.c:197 mm/usercopy.c:258 mm/usercopy.c:223)
copy_header_to_ring (fs/fuse/dev_uring.c:618)
fuse_uring_prepare_send (fs/fuse/dev_uring.c:776 fs/fuse/dev_uring.c:785)
fuse_uring_send_in_task (fs/fuse/dev_uring.c:1306)
tctx_task_work_run (io_uring/tw.c:96)
task_work_run (kernel/task_work.c:233)
io_run_task_work (io_uring/tw.h:84)
io_cqring_wait (io_uring/wait.c:278)
__do_sys_io_uring_enter (io_uring/io_uring.c:2685)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

Bounce both headers through an on-stack copy so the usercopy touches
stack memory, not the slab object.

🎖@cveNotify

🚨 CVE-2026-80948
In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start()

In iwl_op_mode_dvm_start(), jumping to out_free_eeprom currently bypasses
the out_free_eeprom_blob label. Consequently, error paths triggered after
successfully parsing the EEPROM free priv->nvm_data but leak
priv->eeprom_blob.

Fix this memory leak by reordering the error handling labels so
that out_free_eeprom falls through to out_free_eeprom_blob.

The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1-rc6.

An x86_64 allyesconfig build showed no new warnings. As we do not have
supported Intel DVM wireless hardware and firmware to test with, no
runtime testing was able to be performed.

🎖@cveNotify

🚨 CVE-2026-80949
In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()

The memory allocated for buf is not freed in some of the error paths in
brcmf_sdio_read_control(). Fix that by adding vfree() calls.

[arend: rework as suggested by Johannes]

🎖@cveNotify

🚨 CVE-2026-80950
In the Linux kernel, the following vulnerability has been resolved:

i3c: renesas: Check that the transfer is valid before accessing it

The Renesas I3C driver uses an asynchronous model to transfer data. It
prepares a struct renesas_i3c_xfer, enqueues it, and waits for completion.
The interrupt handler dequeues the transfer, updates/uses it, and signals
the waiting thread.

If the completion times out, the waiting thread dequeues the transfer and
free it. If an interrupt fires after that, the handler may access freed
memory, leading to crashes.

Check that the transfer is still valid before accessing it in the
interrupt handler. With it clear any status flags and disable all
the interrupts to avoid triggering the same interrupts again.

🎖@cveNotify

🚨 CVE-2026-80951
In the Linux kernel, the following vulnerability has been resolved:

i3c: master: svc: bound IBI payload to the requested max_payload_len

svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into
the IBI slot. The loop is bounded by the hardware FIFO size
(SVC_I3C_FIFO_SIZE), not by the slot size.

slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool()
sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only
rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can
request a smaller one. mctp-i3c requests 1. Each readsb() then copies the
controller RXCOUNT bytes (up to 31) with no check against the slot size.
A device that sends more bytes than the slot holds writes past
slot->data, an out-of-bounds write into the IBI pool.

Bound the loop by dev->ibi->max_payload_len and clamp each read to the
space left in the slot, the same way dw-i3c does. A device can still send
more than the requested payload. Flush the leftover bytes from the RX FIFO
so they do not leak into the next transfer.

🎖@cveNotify

🚨 CVE-2026-80952
In the Linux kernel, the following vulnerability has been resolved:

i3c: master: Fix info leak and UAF in device unregister path

i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before
calling device_unregister(). During device_unregister(),
device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while
the device descriptor is still expected to be valid. As a result,
i3c_device_uevent() and a racing modalias_show() can observe a NULL
desc and fall back to an uninitialized stack struct i3c_device_info,
leaking kernel stack contents in the generated modalias. Driver
.remove() callbacks may also encounter an unexpected NULL desc during
unbind.

Keep desc valid until device_unregister() has completed. Since
device_unregister() drops the device reference and may free the device,
take an extra reference with get_device() before unregistering. Clear
desc afterwards and release the extra reference with put_device().
This preserves the release-time invariant that desc must be NULL while
avoiding both the information leak and a potential use-after-free from
writing desc after the device has been released.

🎖@cveNotify

🚨 CVE-2026-80953
In the Linux kernel, the following vulnerability has been resolved:

i3c: master: adi: initialize the lock before enabling interrupts

adi_i3c_master_probe() requests the IRQ and unmasks REG_IRQ_PENDING_CMDR
before the controller's IBI state, transfer queue list and transfer
queue lock are initialized. A pending CMDR interrupt can therefore run
adi_i3c_master_irq() and take master->xferqueue.lock before the dynamic
lock has been initialized.

This issue was found by our static analysis tool and then manually
reviewed against the current tree.

The grounded PoC kept the probe ordering and the IRQ path
adi_i3c_master_probe() -> adi_i3c_master_irq() -> xferqueue.lock, with a
pending CMDR interrupt arriving after REG_IRQ_PENDING_CMDR is unmasked.
Lockdep reported:

INFO: trying to register non-static key.
you didn't initialize this object before use?
lock_acquire+0xbb/0x290
_raw_spin_lock_irqsave+0x36/0x60
adi_i3c_master_irq+0x32/0x56 [vuln_msv]
adi_i3c_master_probe+0x5a/0xf47 [vuln_msv]

Initialize the transfer queue and IBI state before requesting and
unmasking the IRQ.

🎖@cveNotify

🚨 CVE-2026-80954
In the Linux kernel, the following vulnerability has been resolved:

i3c: Fix unlocked dereference of dev->desc in i3c_device_get_supported_xfer_mode()

i3c_device_get_supported_xfer_mode() uses dev->desc to obtain the
master controller. However, dev->desc must not be dereferenced unless
bus->lock is held, and this function does not take that lock.

The function only needs access to the master controller associated with
the device's bus. Use dev->bus instead, which is always valid for the
lifetime of the device and does not require dereferencing dev->desc.

🎖@cveNotify

🚨 CVE-2026-80955
In the Linux kernel, the following vulnerability has been resolved:

dm-pcache: fix use-after-free and invalid seg operations in kset_replay()

In kset_replay, when key->seg_gen is stale (key->seg_gen <
key->cache_pos.cache_seg->gen), cache_key_put(key) is called but then
key->cache_pos.cache_seg is accessed as the argument to cache_seg_get().
This is a use-after-free on the freed key memory. Although mempool
recycled memory is not immediately reclaimed or overwritten in practice,
this is still a potential UAF bug.

Additionally, for expired invalid keys, setting the cache->seg_map bit
and calling cache_seg_get() is unreasonable since the corresponding
segment data is no longer valid.

Fix both issues by moving cache_seg_get() and __set_bit() after the
gen check, so they only execute for valid keys, and using continue to
skip invalid keys.

🎖@cveNotify

🚨 CVE-2026-80956
In the Linux kernel, the following vulnerability has been resolved:

dm-pcache: only hand out initialized cache segments

get_cache_segment() scans the segment map up to cache->n_segs, the
physical device segment count, but cache_segs_init() only initializes
the first cache_info->n_segs segments. A crafted image with
cache_info->n_segs smaller than the device count leaves the remaining
pcache_cache_segment structs zeroed (segment.data == NULL), and the
allocator can hand one to cache_kset_close(), which writes through the
returned segment's data pointer with no NULL check.

Bound the allocator's search to cache_info->n_segs so only initialized
segments are ever returned. A conforming cache sets n_segs equal to the
device segment count, so this rejects nothing legitimate.

🎖@cveNotify

🚨 CVE-2026-80957
In the Linux kernel, the following vulnerability has been resolved:

dm-pcache: detect a cycle in the last-kset chain during replay

cache_replay() follows the on-media last-kset chain by next_cache_seg_id
with no cond_resched(). A forged chain that points back into a segment it
has already visited makes the replay loop follow it forever.

Cap the last-kset hops at cache->n_segs; a valid chain visits each segment
at most once.

🎖@cveNotify

🚨 CVE-2026-80958
In the Linux kernel, the following vulnerability has been resolved:

dm-pcache: clamp the tail kset read to the segment data region

The tail-kset read in cache_replay(), the writeback worker and the GC
worker bounds its length by PCACHE_SEG_SIZE - seg_off, the raw segment
size rather than the data region. A tail near the segment end reads past
the segment data into the following control area.

Clamp the read to cache_seg_remain(), the data region.

🎖@cveNotify

🚨 CVE-2026-80959
In the Linux kernel, the following vulnerability has been resolved:

dm-pcache: bound the persisted tail-position offset

cache_pos_decode() takes the persisted key_tail and dirty_tail seg_off from
the cache device and addresses within the segment with it. A seg_off at or
past the segment data_size, controllable by whoever supplies the device
(CAP_SYS_ADMIN), reads past the segment data.

Reject a decoded seg_off that is not below the segment data_size.

🎖@cveNotify