CVE Vulnerability Catalog

In the Linux kernel, i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During unregister, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct, leaking kernel stack contents. A use-after-free may also occur from writing desc after the device is released.

In the Linux kernel, svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the slot, bounding the loop by the hardware FIFO size (SVC_I3C_FIFO_SIZE) rather than the slot size. A driver can request a smaller max_payload_len (e.g., mctp-i3c requests 1), so a device sending more bytes writes past slot->data, an out-of-bounds write into the IBI pool.

In the Linux kernel, the Renesas I3C driver uses an asynchronous model: it prepares a struct renesas_i3c_xfer, enqueues it, and waits for completion. If completion times out, the waiting thread dequeues and frees the transfer; a later interrupt may access freed memory, causing crashes.

In the Linux kernel, brcmf_sdio_read_control() does not free the memory allocated for buf in some error paths. The fix adds vfree() calls in those paths.

In the Linux kernel, iwl_op_mode_dvm_start() in the iwlwifi dvm driver: jumping to out_free_eeprom bypasses the out_free_eeprom_blob label. Consequently, error paths after successfully parsing the EEPROM free priv->nvm_data but leak priv->eeprom_blob. The fix reorders the error handling labels.

In the Linux kernel, the rtl8xxxu wifi driver has a use-after-free bug involving the rx_urb_wq workqueue. rtl8xxxu_stop() does not cancel rx_urb_wq, so a worker can run after rtl8xxxu_disconnect() frees the priv structure, causing a use-after-free. The issue occurs under active RX traffic followed by a disconnect.

In the Linux kernel, the fuse-io-uring transport copies req->in.h and req->out.h directly to/from userspace in fuse_uring_copy_to_ring() and fuse_uring_commit(). The headers live in the fuse_request slab object, whose cache lacks a usercopy whitelist, tripping CONFIG_HARDENED_USERCOPY and causing a kernel panic.

In the Linux kernel, the iaa crypto driver has a bug during hardware decompression. On a hardware analytics error, the decompress path retries through the software fallback, which writes req->dst while it is still mapped as DMA_FROM_DEVICE. With SWIOTLB active, the later dma_unmap_sg() copies the stale bounce buffer over req->dst, corrupting the result.

In the Linux kernel, the mwifiex Wi-Fi driver fails to detach the caller-provided data buffer from a still-current synchronous command when the wait is interrupted. A late firmware response can then write through a stale stack pointer, causing kernel stack corruption and a panic.

In the Linux kernel, the rtlwifi driver (rtl8192du) uses the QoS TID from the 802.11 header as an index into sta_entry->tids[] in rtl92du_tx_fill_desc(). Since ieee80211_get_tid() returns a value in the range 0..15 while the array only has MAX_TID_COUNT (9) entries, a TID greater than 8 indexes past the aggregation state array.

In the Linux kernel, the rtlwifi driver (rtl8192du) does not free memory allocated inside rtl92du_init_shared_data() in any of the subsequent error paths in rtl92du_init_sw_vars(). This leads to a memory leak.

In the Linux kernel, the rtw88 wifi driver's rtw_txq_push_skb() does not free the skb before returning on the error path, even though rtw_hci_tx_write() expects the skb to be freed on failure. This leads to a memory leak in rtw_txq_push().

In the Linux kernel, the rtw88 wifi driver (PCI) allocates PCI resources via rtw_pci_setup_resource() before setting up NAPI in rtw_pci_probe(). If rtw_pci_napi_init() fails, the error path skips rtw_pci_destroy(), leaving the allocated PCI resources behind.

In the Linux kernel, the rtw89 WiFi PCI driver lacked a .shutdown callback to stop rfkill polling during reboot. As a result, arm64 platforms could panic with an asynchronous SError when the driver performed an MMIO read after the PCIe link was torn down. A new rtw89_pci_shutdown() function sets the RTW89_FLAG_SHUTDOWN flag, causing rtw89_ops_rfkill_poll() to return early.

In the Linux kernel, the mt76 wifi driver (mt7615) acquires the mt76 mutex in mt7615_suspend() and then calls cancel_delayed_work_sync() on mac_work. Since mt7615_mac_work() also acquires the same mutex, if mac_work is already running and blocked on the mutex, the suspend path deadlocks.

In the Linux kernel, the mt76 wifi driver (mt7915) copies a fixed EFUSE block into dev->mt76.eeprom.data at the offset reported by the MCU (res->addr) in mt7915_mcu_get_eeprom() without checking it against the buffer size. A malicious or malfunctioning device can report an arbitrary address and drive a 16-byte out-of-bounds write past eeprom.data.

In the Linux kernel, the mt76 wifi driver (mt7925) queues mlo_pm_work with a 5 second delay during multi-link power-save setup and never cancels it on the stop path. If the device is torn down within that window, the work outlives the teardown and its timer fires afterwards, trying to queue onto a workqueue that is already gone.

In the Linux kernel, mt7996_mcu_get_eeprom() in the mt76 wifi driver (mt7996 chipset) derives the destination of the EFUSE/EXT block copy from the address reported by the MCU response (event->addr) and clamps only the copy length, never the destination offset into dev->mt76.eeprom.data. A malicious or malfunctioning device can report an arbitrary address and drive an out-of-bounds write of up to MT7996_EXT_EEPROM_BLOCK_SIZE bytes past eeprom.data.

In the Linux kernel, mt7996/mt7992 hand the firmware a HW MAC-TXP for AddBA req action frames but are otherwise FW-TXP devices. On tx free, mt76_connac_txp_skb_unmap() decodes the per-frame txp as a struct mt76_connac_fw_txp, so the unmap loop runs zero times and the skb DMA mapping in buf[1] is never unmapped. Each AddBA req leaks one TX DMA mapping, exhausting the WED swiotlb pool after ~1-2 days under continuous client reconnect churn.

In the Linux kernel, the default EEPROM firmware is parsed and copied as a full EEPROM without checking its length. A truncated file can make the driver read beyond the firmware buffer during variant validation or the fallback copy.