Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: free iso schedules on failed submit<br /> <br /> EHCI and FOTG210 isochronous submits build an ehci_iso_sched before<br /> linking the URB to the endpoint queue, and keep the staged schedule in<br /> urb-&gt;hcpriv until iso_stream_schedule() and the link helpers consume it.<br /> If the controller is no longer accessible, or usb_hcd_link_urb_to_ep()<br /> fails, submit jumps to done_not_linked before that handoff happens and<br /> leaks the staged schedule still attached to urb-&gt;hcpriv.<br /> <br /> Free the staged schedule from done_not_linked when submit fails before<br /> the URB is linked and clear urb-&gt;hcpriv after the free.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available. Manual inspection confirms that the bug is still<br /> present in v7.1.1.<br /> <br /> An x86_64 allyesconfig build showed no new warnings. As we do not have an<br /> EHCI host controller with a USB isochronous device to test with, no<br /> runtime testing was able to be performed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()<br /> <br /> The dwc3_ulpi_setup() calls the register read and write calls with<br /> dwc3-&gt;regs when both these calls take the dwc3 structure directly.<br /> <br /> Chnage these two calls to fix the following sparse warning, and<br /> possibly a nasty bug in the dwc3_ulpi_setup() code:<br /> <br /> drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces)<br /> drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc<br /> drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs<br /> drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces)<br /> drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc<br /> drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()<br /> <br /> cdnsp_alloc_stream_info() allocates stream_info-&gt;stream_ctx_array with<br /> cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream<br /> mapping update fails, the error path frees the allocated stream rings<br /> and stream_rings array, but leaves stream_ctx_array allocated.<br /> <br /> Free the stream context array before falling through to the stream_rings<br /> cleanup path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()<br /> <br /> kalmia_rx_fixup() computes usb_packet_length = skb-&gt;len - (2 *<br /> KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that<br /> skb-&gt;len is at least KALMIA_HEADER_LENGTH, which is 6. A device can<br /> deliver a short bulk-IN frame with skb-&gt;len in the 6 to 11 range, or<br /> leave a short trailing remainder on a later loop iteration. Either case<br /> underflows usb_packet_length to about 65530.<br /> <br /> That bypasses the usb_packet_length

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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")

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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")

*** Pendiente de traducción *** 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")