Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Allow LPM map access from sleepable BPF programs<br /> <br /> trie_lookup_elem() annotates its rcu_dereference_check() walks with<br /> only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c)<br /> resolves to "c || rcu_read_lock_held()", this passes for XDP/NAPI and<br /> classic RCU readers but fails for sleepable BPF programs, which enter<br /> via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace().<br /> <br /> trie_update_elem() and trie_delete_elem() have the same problem in a<br /> different form: they walk the trie with plain rcu_dereference(), which<br /> asserts rcu_read_lock_held() unconditionally. Both are reachable from<br /> sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem<br /> helpers, and from the syscall path under classic rcu_read_lock(). In<br /> the writer paths the trie is actually protected by trie-&gt;lock (an<br /> rqspinlock taken across the walk); we never relied on the RCU read-side<br /> lock to keep nodes alive there.<br /> <br /> A sleepable LSM hook that ends up touching an LPM trie therefore<br /> triggers lockdep on debug kernels:<br /> <br /> =============================<br /> WARNING: suspicious RCU usage<br /> 7.1.0-... Tainted: G E<br /> -----------------------------<br /> kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage!<br /> 1 lock held by net_tests/540:<br /> #0: (rcu_tasks_trace_srcu_struct){....}-{0:0},<br /> at: __bpf_prog_enter_sleepable+0x26/0x280<br /> Call Trace:<br /> dump_stack_lvl<br /> lockdep_rcu_suspicious<br /> trie_lookup_elem<br /> bpf_prog_..._enforce_security_socket_connect<br /> bpf_trampoline_...<br /> security_socket_connect<br /> __sys_connect<br /> do_syscall_64<br /> <br /> This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize<br /> against the trie&amp;#39;s reclaim path -- but it spams the console once per<br /> distinct callsite on every debug kernel running a sleepable BPF LSM<br /> that touches an LPM trie, which is increasingly common.<br /> <br /> For the lookup path, switch the rcu_dereference_check() annotation<br /> from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all<br /> three contexts (classic, BH, Tasks Trace). Other map types already<br /> follow this convention.<br /> <br /> For trie_update_elem() and trie_delete_elem(), annotate the walks as<br /> rcu_dereference_protected(*p, 1) -- matching trie_free() in the same<br /> file -- since trie-&gt;lock is held across the walk. rqspinlock has no<br /> lockdep_map, so the predicate degenerates to &amp;#39;1&amp;#39; rather than<br /> lockdep_is_held(&amp;trie-&gt;lock); the protection is real but not<br /> machine-verifiable. trie_get_next_key() also uses bare<br /> rcu_dereference() but is reachable only from the BPF syscall, which<br /> holds classic rcu_read_lock() before dispatching, so it is left<br /> untouched.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Keep dynamic inner array lookups nullable<br /> <br /> An ARRAY_OF_MAPS can use an array created with BPF_F_INNER_MAP as its<br /> inner map template. A concrete inner array with a different max_entries<br /> value can then replace the template.<br /> <br /> After a successful outer map lookup, the verifier represents the<br /> resulting map pointer using the inner map template. Const-key lookup<br /> nullness elision consequently uses the template max_entries even though<br /> the runtime helper uses the concrete inner map max_entries.<br /> <br /> Do not elide lookup result nullness for maps marked with BPF_F_INNER_MAP,<br /> because the template max_entries does not prove that the key is in bounds<br /> for the concrete runtime map.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Validate BTF repeated field counts before expansion<br /> <br /> btf_parse_struct_metas() walks user-supplied BTF during BPF_BTF_LOAD,<br /> and btf_repeat_fields() expands repeatable fields from array elements<br /> into the fixed BTF_FIELDS_MAX scratch array used by btf_parse_fields().<br /> <br /> The remaining-capacity check performs the expanded field count calculation<br /> in u32. A malformed BTF can wrap that calculation, causing the check to<br /> pass even when the expanded field count exceeds the scratch array<br /> capacity. The following memcpy() can then write past the end of the<br /> array.<br /> <br /> Use checked addition and multiplication before copying repeated fields<br /> and reject impossible counts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject fragmented frames in devmap<br /> <br /> Devmap broadcast redirects clone the packet for all but the last<br /> destination.<br /> <br /> For native XDP, that clone path copies only the linear xdp_frame data,<br /> while fragmented frames keep skb_shared_info in tailroom outside the<br /> linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but<br /> without valid frag metadata, and the later free path can interpret<br /> uninitialized tail data as skb_shared_info, leading to an out-of-bounds<br /> access during frame return.<br /> <br /> Reject fragmented native XDP frames in dev_map_enqueue_clone().<br /> <br /> Add the same restriction to the generic XDP clone path in<br /> dev_map_redirect_clone(). Generic XDP represents fragmented packets as<br /> nonlinear skbs, and rejecting them here keeps clone-based broadcast<br /> support aligned between native and generic XDP.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: iowarrior: 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 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: iowarrior: fix use-after-free on disconnect<br /> <br /> Submitted write URBs are not stopped on close() and therefore need to be<br /> stopped unconditionally on disconnect() to avoid use-after-free in the<br /> completion handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: ldusb: 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: idmouse: 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: gadget: f_printer: take kref only for successful open<br /> <br /> printer_open() returns -EBUSY when the character device is already<br /> open, but it increments dev-&gt;kref regardless of the return value. VFS<br /> does not call -&gt;release() for a failed open, so every rejected second<br /> open permanently leaks one reference.<br /> <br /> Move kref_get() into the successful-open branch.

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.