Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler<br /> <br /> The OTG branch of composite_setup() falls back to the first<br /> configuration when none is selected:<br /> <br /> if (cdev-&gt;config)<br /> config = cdev-&gt;config;<br /> else<br /> config = list_first_entry(&amp;cdev-&gt;configs,<br /> struct usb_configuration, list);<br /> if (!config)<br /> goto done;<br /> ...<br /> memcpy(req-&gt;buf, config-&gt;descriptors[0], value);<br /> <br /> list_first_entry() never returns NULL. On an empty list it returns<br /> container_of() of the list head. So the "if (!config)" check is dead.<br /> <br /> When cdev-&gt;configs is empty, config points at the head inside struct<br /> usb_composite_dev. config-&gt;descriptors[0] reads whatever sits at that<br /> offset. The memcpy copies up to w_length bytes of it into the response<br /> buffer.<br /> <br /> cdev-&gt;configs can be empty in two cases. One is a teardown race on<br /> gadget unbind with a control transfer in flight. The other is a driver<br /> that sets is_otg before it adds a config. A reproducer that holds<br /> cdev-&gt;configs empty triggers a KASAN fault in this branch.<br /> <br /> Use list_first_entry_or_null() so the existing check does its job.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: udc: Fix use-after-free in gadget_match_driver<br /> <br /> The udc structure acts as the management structure for the gadget,<br /> but their lifecycles are decoupled. A race condition exists where<br /> usb_del_gadget() frees the udc memory (e.g., via mode-switch work)<br /> while gadget_match_driver() concurrently accesses the freed udc memory<br /> (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a<br /> NULL pointer dereference when the freed memory is zeroed:<br /> <br /> [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140<br /> [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60<br /> ...<br /> [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8<br /> [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140<br /> [39430.931308][ T1171] configfs_write_iter+0xec/0x134<br /> <br /> [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode<br /> [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c<br /> [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664<br /> <br /> Fix this by ensuring the udc structure remains allocated until the<br /> gadget is released. To achieve this, introduce a new<br /> usb_gadget_release() routine to the core. When the gadget is added,<br /> usb_add_gadget() stores the gadget&amp;#39;s release routine in the udc<br /> structure and takes a reference to the udc. When the gadget is<br /> released, usb_gadget_release() drops the reference to the udc and<br /> then calls the gadget&amp;#39;s release routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: digi_acceleport: fix hard lockup on disconnect<br /> <br /> If submitting the OOB write urb fails persistently (e.g if the device is<br /> being disconnected) the driver would loop indefinitely with interrupts<br /> disabled.<br /> <br /> Check for urb submission errors when sending OOB commands to avoid<br /> hanging if, for example, open(), set_termios() or close() races with a<br /> physical disconnect.<br /> <br /> This is issue was flagged by Sashiko when reviewing an unrelated change<br /> to the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: digi_acceleport: fix broken rx after throttle<br /> <br /> If the port is closed while throttled, the read urb is never resubmitted<br /> and the port will not receive any further data until the device is<br /> reconnected (or the driver is rebound).<br /> <br /> Clear the throttle flags and submit the urb if needed when opening the<br /> port.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: keyspan_pda: fix information leak<br /> <br /> The write() callback is supposed to return the number of characters<br /> accepted or a negative errno. Since the addition of write fifo support<br /> the keyspan_pda implementation will however return the number characters<br /> submitted to the device if the write urb is not already in use. If this<br /> number is larger than the number of characters passed to write(), the<br /> line discipline continues writing data from beyond the tty write buffer.<br /> <br /> Fix the information leak by making sure that keyspan_pda_write_start()<br /> returns zero on success as intended.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: mtu3: unmap request DMA on queue failure<br /> <br /> mtu3_gadget_queue() maps the request before checking whether<br /> the QMU GPD ring can accept another transfer. the request is<br /> returned with -EAGAIN before it is linked on the endpoint<br /> request list if mtu3_prepare_transfer() fails.<br /> <br /> Normal completion and dequeue paths unmap requests from<br /> mtu3_req_complete(), but this error path never reaches that<br /> helper, so the DMA mapping is left active. Unmap the request<br /> before returning from the failed queue path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: misc: uss720: unregister parport on probe failure<br /> <br /> uss720_probe() registers a parport before reading the 1284 register used<br /> to detect unsupported Belkin F5U002 adapters. If get_1284_register()<br /> fails, the error path drops the driver private data and the USB device<br /> reference, but leaves the parport device registered.<br /> <br /> Leaving the port registered is more than a private allocation leak:<br /> parport_register_port() has already reserved a parport number and<br /> registered the parport bus device, while pp-&gt;private_data still points at<br /> the private data that the common error path is about to release.<br /> <br /> Undo the pre-announce registration in the get_1284_register() failure<br /> branch before jumping to the common private-data cleanup path. Clear<br /> priv-&gt;pp first, matching the disconnect path and avoiding a stale pointer<br /> in the private data.<br /> <br /> This issue was identified during our ongoing static-analysis research while<br /> reviewing kernel code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: misc: usbio: bound bulk IN response length to the received transfer<br /> <br /> usbio_bulk_msg() copies bpkt_len = le16_to_cpu(bpkt-&gt;len) bytes out of<br /> the bulk IN buffer (usbio-&gt;rxbuf, allocated with size usbio-&gt;rxbuf_len)<br /> into the caller&amp;#39;s buffer. bpkt_len is fully controlled by the device<br /> and is only checked against ibuf_len; ibuf_len in turn is checked<br /> against usbio-&gt;txbuf_len, not against rxbuf_len:<br /> <br /> if ((obuf_len &gt; (usbio-&gt;txbuf_len - sizeof(*bpkt))) ||<br /> (ibuf_len &gt; (usbio-&gt;txbuf_len - sizeof(*bpkt))))<br /> return -EMSGSIZE;<br /> <br /> txbuf_len and rxbuf_len are taken independently from the bulk OUT and<br /> bulk IN endpoint wMaxPacketSize in usbio_probe(). A malicious or<br /> malfunctioning device that advertises a large bulk OUT endpoint and a<br /> small bulk IN endpoint (e.g. by claiming one of the quirk-free IDs such<br /> as the Lattice NX33U, 0x2ac1:0x20cb) therefore makes ibuf_len, and<br /> hence the device-supplied bpkt_len, exceed rxbuf_len. memcpy() then<br /> reads up to txbuf_len - rxbuf_len bytes past the end of the rxbuf slab<br /> object. The over-read bytes are handed back to the i2c layer and on to<br /> user space through i2c-dev, disclosing adjacent slab memory; with KASAN<br /> this is reported as a slab-out-of-bounds read.<br /> <br /> The number of bytes actually received is already known: act equals the<br /> URB actual_length and is bounded by rxbuf_len. Reject any response<br /> that claims more payload than was received, mirroring the existing<br /> "act

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: legousbtower: fix use-after-free on disconnect race<br /> <br /> mutex_unlock() may access the mutex structure after releasing the lock<br /> and therefore cannot be used to manage lifetime of objects directly<br /> (unlike spinlocks and refcounts). [1][2]<br /> <br /> Use a kref to release the driver data to avoid use-after-free in<br /> mutex_unlock() when release() races with disconnect().<br /> <br /> [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is<br /> non-atomic")<br /> [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most<br /> other sleeping locks, can still use the lock object<br /> after it&amp;#39;s unlocked")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: digi_acceleport: fix write buffer corruption<br /> <br /> The digi_write_inb_command() is supposed to wait for the write urb to<br /> become available or return an error, but instead it updates the transfer<br /> buffer and tries to resubmit the urb on timeout.<br /> <br /> To make things worse, for commands like break control where no timeout<br /> is used, the driver would corrupt the urb immediately due to a broken<br /> jiffies comparison (on 32-bit machines this takes five minutes of uptime<br /> to trigger due to INITIAL_JIFFIES).<br /> <br /> Fix this by adding the missing return on timeout and waiting<br /> indefinitely when no timeout has been specified as intended.<br /> <br /> This issue was (sort of) flagged by Sashiko when reviewing an unrelated<br /> change to the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon<br /> <br /> This patch is based on a BUG as reported by Bongani Hlope at<br /> https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/<br /> <br /> When a channel-switch announcement (CSA) beacon is received,<br /> cfg80211 queues a wiphy work item that eventually calls<br /> mt7921_channel_switch_rx_beacon(). If the station disconnects<br /> (or the channel context is otherwise torn down) between the<br /> time the work is queued and the time it runs, the driver&amp;#39;s<br /> dev-&gt;new_ctx pointer can already have been cleared to NULL.<br /> mt7921_channel_switch_rx_beacon() then dereferences new_ctx<br /> unconditionally, triggering a NULL pointer dereference at<br /> address 0x0:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:mt7921_channel_switch_rx_beacon+0x1f/0x100 [mt7921_common]<br /> <br /> The same missing guard exists in mt7925_channel_switch_rx_beacon(),<br /> which shares the same code pattern introduced by the same commit.<br /> <br /> Add an early-return NULL check for dev-&gt;new_ctx in both<br /> mt7921_channel_switch_rx_beacon() and<br /> mt7925_channel_switch_rx_beacon(). When new_ctx is NULL there is<br /> no pending channel switch to process, so returning immediately is<br /> the correct and safe action.<br /> <br /> Oops-Analysis: http://oops.fenrus.org/reports/lkml/20260502125824.425d7159@bongani-mini.home.org.za/report.html

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: skip sync_blockdev() on surprise removal in bdev_mark_dead()<br /> <br /> bdev_mark_dead()&amp;#39;s @surprise == true means the device is already gone.<br /> The filesystem callback fs_bdev_mark_dead() honours this and skips<br /> sync_filesystem(), but the bare block device path (no -&gt;mark_dead op)<br /> lost its !surprise guard when the holder -&gt;mark_dead callback was wired<br /> up (see Fixes), and now calls sync_blockdev() unconditionally, which can<br /> hang forever waiting on writeback that can no longer complete.<br /> <br /> syzkaller hit this via nvme_reset_work()&amp;#39;s "I/O queues lost" path:<br /> nvme_mark_namespaces_dead() -&gt; blk_mark_disk_dead() -&gt;<br /> bdev_mark_dead(bdev, true) -&gt; sync_blockdev() blocks in<br /> folio_wait_writeback(), wedging the reset worker and every task waiting<br /> on it.<br /> <br /> Skip the sync on surprise removal, matching fs_bdev_mark_dead();<br /> invalidate_bdev() still runs. Orderly removal (surprise == false) is<br /> unchanged.<br /> <br /> Found by FuzzNvme(Syzkaller with FEMU fuzzing framework).