Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Move jump_label_init() before parse_early_param()<br /> <br /> When enabling both CONFIG_MEM_ALLOC_PROFILING=y and<br /> CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y, then diabling memory<br /> profiling by adding the boot parameter &amp;#39;sysctl.vm.mem_profiling=0&amp;#39; will<br /> cause the kernel failed to boot.<br /> <br /> After analysis, this is because jump_label_init() must be called before<br /> parse_early_param(), the early param handlers may modify static keys by<br /> static_branch_enable/disable().<br /> <br /> Fix this by moving jump_label_init() to before parse_early_param(). The<br /> solution is similar to other architectures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: comedi_parport: deal with premature interrupt<br /> <br /> Syzbot reported a general protection fault in<br /> `comedi_get_is_subdevice_running()`, which was called from the interrupt<br /> handler `parport_interrupt()` in the "comedi_parport" driver, but it<br /> does not currently have a C reproducer for the problem. It&amp;#39;s<br /> probably due to a premature interrupt for one of two reasons:<br /> <br /> 1. The driver sets up the interrupt handler before the comedi subdevices<br /> used by the interrupt handler have been allocated, but does not<br /> disable the interrupt in the parallel port&amp;#39;s CTRL register first.<br /> 2. The driver uses a user-supplied I/O port base address which Syzbot<br /> would have supplied, but it might not be backed by real parallel port<br /> hardware.<br /> <br /> Change the initialization order in the driver&amp;#39;s comedi "attach" handler<br /> (`parport_attach()`) so that the hardware registers are initialized<br /> before the interrupt handler is requested. This should prevent<br /> premature interrupts occurring for real hardware.<br /> <br /> Also add a test to the interrupt handler to ensure the comedi device is<br /> fully attached and return early if it isn&amp;#39;t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: stratix10-svc: fix memory leaks and list corruption bugs<br /> <br /> Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error<br /> path. Switch pmem allocation from devm_kzalloc() to kzalloc() with<br /> explicit kfree() in the free path to match its list-managed lifetime.<br /> Remove the erroneous list_del(&amp;svc_data_mem) which corrupted the list head<br /> on failed lookups.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cdrom: fix stack out-of-bounds read in CDROMVOLCTRL<br /> <br /> mmc_ioctl_cdrom_volume() first reads the audio control mode page into a<br /> 32-byte stack buffer with cgc-&gt;buflen set to 24. If the device reports a<br /> block descriptor, the function increases cgc-&gt;buflen to include that<br /> descriptor and reads the page again.<br /> <br /> For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list<br /> by moving cgc-&gt;buffer forward by offset - 8 bytes. This drops the block<br /> descriptor from the outgoing payload and leaves a new 8-byte mode<br /> parameter header in front of the audio control page. However, cgc-&gt;buflen<br /> is left unchanged.<br /> <br /> With a standard 8-byte block descriptor, cgc-&gt;buffer points at buffer + 8<br /> but cgc-&gt;buflen remains 32. cdrom_mode_select() therefore asks the low<br /> level packet path to write 32 bytes from that adjusted pointer, reading 8<br /> bytes past the end of the 32-byte stack buffer.<br /> <br /> This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on<br /> drives that return a non-zero block descriptor length, which helps explain<br /> why it has gone unnoticed. The overread is also sent to the device as<br /> extra MODE SELECT payload, so it may not produce an obvious local failure.<br /> <br /> Reduce cgc-&gt;buflen by the same amount as the buffer pointer adjustment so<br /> the MODE SELECT transfer covers only the intended parameter list.