Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper<br /> <br /> mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on<br /> bss_desc-&gt;bcn_ht_cap being present, but then dereferences a different<br /> pointer, bss_desc-&gt;bcn_ht_oper:<br /> <br /> if (ISSUPP_CHANWIDTH40(priv-&gt;adapter-&gt;hw_dot_11n_dev_cap) &amp;&amp;<br /> bss_desc-&gt;bcn_ht_cap &amp;&amp;<br /> ISALLOWED_CHANWIDTH40(bss_desc-&gt;bcn_ht_oper-&gt;ht_param))<br /> <br /> bcn_ht_cap and bcn_ht_oper are populated independently while parsing the<br /> associated AP&amp;#39;s beacon in mwifiex_update_bss_desc_with_ie(): an AP that<br /> advertises an HT Capabilities element but no HT Operation element leaves<br /> bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a<br /> peer while associated to such an AP then dereferences the NULL<br /> bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the<br /> driver NULL-checks it first.<br /> <br /> Guard on the pointer that is actually dereferenced.<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: fix OOB access from firmware ADDBA window size<br /> <br /> aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied<br /> win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not<br /> return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to<br /> compute a kzalloc size and stored in rxtid-&gt;hold_q_sz, leading to<br /> zero-size or overflowed allocations and subsequent out-of-bounds access.<br /> <br /> Clean up any previously active aggregation session for the TID first,<br /> then return early when win_sz is out of the valid range, instead of<br /> proceeding with a broken allocation size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: close a re-opened queue timer in the destructor<br /> <br /> queue_delete() closes the queue timer, then frees it. snd_seq_timer_close()<br /> clears q-&gt;timer-&gt;timeri. snd_use_lock_sync() then drains borrowers, and<br /> snd_seq_timer_delete() frees q-&gt;timer.<br /> <br /> A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT<br /> that took a queueptr() use_lock reference before the queue was unlinked<br /> runs snd_seq_timer_open() after the close. Open refuses re-open only while<br /> timeri is set, and the close just cleared it, so it re-opens timeri.<br /> <br /> snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop()<br /> is a no-op, because running was cleared first. So it frees q-&gt;timer with the<br /> instance still live. The queue is freed next.<br /> <br /> The instance stays on the global timer with callback_data pointing at the<br /> freed queue. A non-owner START on the unlocked queue arms it. The next tick<br /> derefs the freed queue in snd_seq_timer_interrupt().<br /> <br /> Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and<br /> no queue ownership required.<br /> <br /> Close any lingering instance in the destructor. There, -&gt;timeri can no<br /> longer change: the queue is unlinked and all use_lock borrowers have<br /> drained, so no snd_seq_queue_use() can re-open it. Close it before clearing<br /> q-&gt;timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt()<br /> to finish, and that callback still reads q-&gt;timer (via snd_seq_check_queue()),<br /> so q-&gt;timer must stay valid until it drains.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix NULL pointer dereference in rhash table destroy<br /> <br /> When unbinding the ath12k driver, kernel NULL pointer dereferences<br /> occur in irq_work_sync() called from rhashtable_destroy().<br /> <br /> Two hash tables are affected:<br /> 1. ath12k_link_sta hash table in ath12k_base<br /> 2. ath12k_dp_link_peer hash table in ath12k_dp<br /> <br /> The issue happens because the destroy functions are called unconditionally<br /> in cleanup paths, but the hash tables are only initialized late in their<br /> respective init functions. If the device was never fully started or if the<br /> init functions failed before initializing the hash tables, the pointers<br /> will be NULL. The issues are always reproducible from a VM because the MSI<br /> addressing initialization is failing.<br /> <br /> Call trace for ath12k_link_sta_rhash_tbl_destroy:<br /> RIP: irq_work_sync+0x1e/0x70<br /> rhashtable_destroy+0x12/0x60<br /> ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k]<br /> ath12k_core_stop+0xe/0x80 [ath12k]<br /> ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k]<br /> ath12k_pci_remove+0x60/0x110 [ath12k]<br /> <br /> Call trace for ath12k_dp_link_peer_rhash_tbl_destroy:<br /> RIP: irq_work_sync+0x1e/0x70<br /> rhashtable_destroy+0x12/0x60<br /> ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k]<br /> ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k]<br /> ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k]<br /> ath12k_pci_remove+0x60/0x110 [ath12k]<br /> <br /> Fix this by adding NULL checks before calling rhashtable_destroy() in<br /> both destroy functions.<br /> <br /> The NULL check approach was chosen because the rhashtable pointer<br /> serves as the initialization state indicator. The init can fail at<br /> various points, leaving some components uninitialized. Checking the<br /> pointer directly is simpler than adding separate state flags that<br /> would need synchronization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses<br /> <br /> PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and<br /> mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus.<br /> mt7925_mac_tx_free() cleans the DMA tx queues with<br /> mt76_queue_tx_cleanup(), which calls queue_ops-&gt;tx_cleanup(). Only the<br /> mmio queue ops implement that callback; on USB it is NULL, so a<br /> TXRX_NOTIFY there calls a NULL pointer in the RX worker:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:0x0<br /> Call Trace:<br /> mt7925_mac_tx_free+0x58/0x350 [mt7925_common]<br /> mt7925_rx_check+0xe2/0x130 [mt7925_common]<br /> mt76u_rx_worker+0x1b9/0x620 [mt76_usb]<br /> <br /> Drop the event on non-mmio buses via mt76_is_mmio(), as in<br /> commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for<br /> non-mmio devices").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: Fix session UAF in set_termios<br /> <br /> rfcomm_tty_set_termios() tests dlc-&gt;session without rfcomm_mutex and<br /> later passes the pointer to rfcomm_send_rpn(). The latter dereferences<br /> both session-&gt;initiator and session-&gt;sock. Meanwhile, krfcommd can<br /> unlink the DLC and free the session while holding rfcomm_mutex.<br /> <br /> The race can proceed as follows:<br /> <br /> TTY ioctl task krfcommd<br /> -------------- --------<br /> load dlc-&gt;session<br /> enter rfcomm_send_rpn()<br /> lock rfcomm_mutex<br /> clear dlc-&gt;session<br /> free session<br /> unlock rfcomm_mutex<br /> read session-&gt;initiator<br /> <br /> KASAN reported:<br /> <br /> BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0<br /> Read of size 4 at addr ffff88810012a850 by task poc/92<br /> <br /> Call Trace:<br /> rfcomm_send_rpn+0x297/0x2a0<br /> rfcomm_tty_set_termios+0x50d/0x850<br /> tty_set_termios+0x596/0x950<br /> set_termios+0x46a/0x6e0<br /> tty_mode_ioctl+0x152/0xbd0<br /> tty_ioctl+0x915/0x1240<br /> __x64_sys_ioctl+0x134/0x1c0<br /> <br /> Allocated by task 92:<br /> rfcomm_session_add+0x9e/0x2e0<br /> rfcomm_dlc_open+0x8b1/0xe00<br /> rfcomm_dev_activate+0x85/0x1a0<br /> rfcomm_tty_open+0x90/0x280<br /> <br /> Freed by task 68:<br /> kfree+0x131/0x3c0<br /> rfcomm_session_del+0x119/0x180<br /> rfcomm_run+0x737/0x4710<br /> <br /> Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies<br /> that the DLC is still attached and sends the RPN frame. Have the TTY<br /> path use the helper and drop its unlocked session check. This keeps the<br /> session valid through both the frame construction and socket send.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Protect UUID list traversal<br /> <br /> The hci_sync conversion moved class-of-device and EIR generation from an<br /> HCI request built under hdev-&gt;lock to asynchronous command sync work.<br /> The worker holds hdev-&gt;req_lock, but that lock does not serialize access<br /> to hdev-&gt;uuids against add_uuid() and remove_uuid(), which update the<br /> list under hdev-&gt;lock.<br /> <br /> The following interleaving can therefore occur:<br /> <br /> CPU0 (command sync work) CPU1 (management socket)<br /> fetch uuid from the list<br /> list_del(&amp;uuid-&gt;list)<br /> kfree(uuid)<br /> read uuid-&gt;size<br /> <br /> KASAN reports the resulting use-after-free:<br /> <br /> BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0<br /> Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call Trace:<br /> eir_create+0xb8f/0xee0<br /> hci_update_eir_sync+0x1c0/0x330<br /> hci_cmd_sync_work+0x13c/0x290<br /> process_one_work+0x63a/0x1070<br /> worker_thread+0x45b/0xd10<br /> <br /> Allocated by task 86:<br /> __kasan_kmalloc+0x8f/0xa0<br /> add_uuid+0x18a/0x4b0<br /> hci_sock_sendmsg+0x1033/0x1ea0<br /> <br /> Freed by task 92:<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x131/0x3c0<br /> remove_uuid+0x25e/0x560<br /> hci_sock_sendmsg+0x1033/0x1ea0<br /> <br /> Hold hdev-&gt;lock while generating and committing the class-of-device and<br /> EIR snapshots. Release it before sending an HCI command, so controller<br /> waits do not happen under the device lock. This protects all UUID list<br /> walks in these paths and restores the serialization lost in the command<br /> sync conversion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()<br /> <br /> rtw_get_wps_ie() iterates over IE data from network frames without<br /> validating that the IE header and payload fit within the remaining<br /> buffer before reading them. Specifically:<br /> <br /> - in_ie[cnt + 1] is read without checking cnt + 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: make release_scratchbuffers idempotent<br /> <br /> brcmf_pcie_release_scratchbuffers() frees the shared.scratch and<br /> shared.ringupd DMA buffers with dma_free_coherent() but does not clear<br /> the pointers afterwards, unlike the sibling release_ringbuffers() which<br /> NULLs commonrings/flowrings/idxbuf on release.<br /> <br /> Both the bus_reset .reset callback (brcmf_pcie_reset) and<br /> brcmf_pcie_remove() call release_scratchbuffers. When reset teardown<br /> has run before removal, remove&amp;#39;s own teardown would call<br /> dma_free_coherent() a second time on the already-freed DMA allocation.<br /> <br /> NULL the pointers after free, matching release_ringbuffers(), so a later<br /> release observes that the allocation has already been released. This<br /> patch makes repeated sequential release safe; the reset-work lifetime is<br /> handled separately by the following patch.<br /> <br /> This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses<br /> <br /> PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and<br /> mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus.<br /> mt7921_mac_tx_free() cleans the DMA tx queues with<br /> mt76_queue_tx_cleanup(), which calls queue_ops-&gt;tx_cleanup(). Only the<br /> mmio queue ops implement that callback; on USB and SDIO it is NULL, so<br /> a TXRX_NOTIFY there calls a NULL pointer in the RX worker:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:0x0<br /> Call Trace:<br /> mt7921_mac_tx_free+0x64/0x310 [mt7921_common]<br /> mt7921_rx_check+0x5f/0xf0 [mt7921_common]<br /> mt76u_rx_worker+0x1b9/0x620 [mt76_usb]<br /> <br /> Drop the event on non-mmio buses via mt76_is_mmio(), as in<br /> commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for<br /> non-mmio devices").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses<br /> <br /> PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and<br /> mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus.<br /> mt7615_mac_tx_free() cleans the DMA tx queues with<br /> mt76_queue_tx_cleanup(), which calls queue_ops-&gt;tx_cleanup(). Only the<br /> mmio queue ops implement that callback; on the mt7663 USB and SDIO<br /> buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX<br /> worker. Same defect as the mt7921 and mt7925 patches in this series.<br /> <br /> Drop the event on non-mmio buses via mt76_is_mmio(), as in<br /> commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for<br /> non-mmio devices").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mei: bus: access mei_device under device_lock on cleanup<br /> <br /> Fix couple of problems in mei_cl_bus_dev_release():<br /> <br /> mei_cl_flush_queues() is running without lock.<br /> bus-&gt;file_list access after mei_dev_bus_put(bus) can become a<br /> use-after-free if this was the last reference to bus.<br /> <br /> Protect queues cleanup and WARN traversal by device lock there<br /> to avoid the concurrent access problems.<br /> Move WARN traversal before mei_dev_bus_put(bus).<br /> <br /> This file uses bus variable name for mei_device, adjust<br /> code of mei_cl_bus_dev_release() to use bus variable too.