Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mediatek: Fix IRQ domain leak when port fails to enable<br /> <br /> When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port<br /> from pcie-&gt;ports and frees the port structure. However, the IRQ domains set<br /> up earlier by mtk_pcie_init_irq_domain() are never freed.<br /> <br /> Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper,<br /> mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when<br /> mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in<br /> the probe error path (during resume, child devices may have active MSI<br /> mappings and the NOIRQ context prohibits sleeping locks),<br /> mtk_pcie_enable_port() is changed to return an error code so callers can<br /> distinguish the two paths and act accordingly.<br /> <br /> This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC<br /> support series.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: altera: Fix resource leaks on probe failure<br /> <br /> The chained IRQ handler is set during probe, but is only removed during the<br /> driver remove(). If pci_host_probe() fails, the handler and INTx IRQ<br /> domain remain set even though the devm-managed host bridge storage<br /> containing struct altera_pcie will be released, leaving the handler with<br /> a stale data pointer.<br /> <br /> Interrupts are also enabled before pci_host_probe() is called. If probe<br /> fails after that point, the controller interrupt source should be disabled<br /> before the chained handler and INTx domain are removed.<br /> <br /> So set the chained handler only after the INTx domain has been created.<br /> Disable controller interrupts during IRQ teardown, and tear the IRQ setup<br /> down if pci_host_probe() fails.<br /> <br /> [mani: commit log]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: sideband: fix ring sg table pages leak<br /> <br /> xhci_ring_to_sgtable() allocates a temporary pages array and<br /> uses it to build the returned sg_table with<br /> sg_alloc_table_from_pages().<br /> <br /> The error paths free the pages array, but the success path<br /> returns the sg_table without freeing it. This leaks the temporary<br /> array every time a sideband client gets an endpoint or event ring<br /> buffer.<br /> <br /> Free the pages array after sg_alloc_table_from_pages() succeeds.<br /> The returned sg_table has its own scatterlist entries and does not<br /> depend on the temporary array after construction.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Fix sleep in atomic context in xhci_free_streams()<br /> <br /> When a USB device with active stream endpoints is disconnected,<br /> xhci_free_streams() is called from the hub_event workqueue to<br /> free the stream resources. It calls xhci_free_stream_info()<br /> while holding xhci-&gt;lock with irqs disabled.<br /> <br /> xhci_free_stream_info() invokes xhci_free_stream_ctx(), which<br /> calls dma_free_coherent() for large stream context arrays.<br /> <br /> dma_free_coherent() can sleep (e.g. via vunmap), triggering<br /> a BUG when called from atomic context.<br /> <br /> Call trace:<br /> dma_free_attrs+0x174/0x220<br /> xhci_free_stream_info+0xd0/0x11c<br /> xhci_free_streams+0x278/0x37c<br /> usb_free_streams+0x98/0xc0<br /> usb_unbind_interface+0x1b8/0x2f8<br /> device_release_driver_internal+0x1d4/0x2cc<br /> device_release_driver+0x18/0x28<br /> bus_remove_device+0x160/0x1a4<br /> device_del+0x1ec/0x350<br /> usb_disable_device+0x98/0x214<br /> usb_disconnect+0xf0/0x35c<br /> hub_event+0xab4/0x19ec<br /> process_one_work+0x278/0x63c<br /> <br /> Fix this by saving the stream_info pointers and clearing the<br /> ep references under the lock, then calling xhci_free_stream_info()<br /> outside the lock where sleeping is allowed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: clear freeze listener on node removal<br /> <br /> Generally userspace is supposed to explicitly clear freeze listeners<br /> before they drop the refcount on the node ref to zero, but there&amp;#39;s<br /> nothing forcing that. Currently, in this scenario the freeze listener<br /> remains in the freeze_listeners rbtree and in the remote node&amp;#39;s freeze<br /> listener list, even though the ref for which the listener is registered<br /> is gone. This could potentially lead to a memory leak due to a refcount<br /> cycle. Thus, remove the freeze listener in this scenario.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: restore RCU grace period in tcp_ao_destroy_sock<br /> <br /> Commit 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU")<br /> removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that<br /> "the destruction of info/keys is delayed until the socket destructor"<br /> and therefore "no one can discover it anymore".<br /> <br /> That argument does not hold for the call site in tcp_connect()<br /> (net/ipv4/tcp_output.c:4327-4332). At that point the socket is in<br /> TCP_SYN_SENT, has already been inserted into the inet ehash by<br /> inet_hash_connect() in tcp_v4_connect(), and is therefore very much<br /> discoverable: any softirq running tcp_v4_rcv() on another CPU can take<br /> the socket out of the ehash, walk into tcp_inbound_hash(), and load<br /> tp-&gt;ao_info via implicit RCU before bh_lock_sock_nested() is taken on<br /> the destroying CPU.<br /> <br /> The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208)<br /> which re-loads tp-&gt;ao_info via rcu_dereference_check(); the re-load can<br /> still observe the (about-to-be-freed) pointer because there is no<br /> synchronize_rcu() between rcu_assign_pointer(tp-&gt;ao_info, NULL) and<br /> tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is<br /> then walked at line 223:<br /> <br /> hlist_for_each_entry_rcu(key, &amp;ao-&gt;head, node, ...)<br /> <br /> The writer&amp;#39;s synchronous kfree() is free to complete between the line<br /> 218 re-fetch and the line 223 hlist iteration. The slab is reused<br /> (or simply LIST_POISON1-stamped if not yet reused) and the iteration<br /> walks attacker-controlled or poison memory in softirq context.<br /> <br /> Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM):<br /> an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET<br /> installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged<br /> TCP-AO segments toward its eventual 4-tuple via raw sockets, then<br /> calls connect(). The md5-wins reconciliation in tcp_connect() fires<br /> tcp_ao_destroy_sock(); the softirq backlog reader on the loopback<br /> NAPI path crashes on the freed ao-&gt;head.first walk:<br /> <br /> Oops: general protection fault, probably for non-canonical<br /> address 0xfbd59c000000002f<br /> KASAN: maybe wild-memory-access in range<br /> [0xdead000000000178-0xdead00000000017f]<br /> CPU: 0 UID: 1000 PID: 100 Comm: repro_userns<br /> RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0<br /> Call Trace: <br /> __tcp_ao_do_lookup+0x107/0x1c0<br /> tcp_ao_inbound_lookup.constprop.0+0x12a/0x200<br /> tcp_inbound_ao_hash+0x5ea/0x1520<br /> tcp_inbound_hash+0x7ce/0x1240<br /> tcp_v4_rcv+0x1e7a/0x3e10<br /> ...<br /> <br /> Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info<br /> and replace the synchronous tcp_ao_info_free() with a call_rcu()<br /> callback. Readers that captured tp-&gt;ao_info before rcu_assign_pointer<br /> NULLed it now see the object remain valid until rcu_read_unlock().<br /> With the patch applied the reproducer runs cleanly for 2000 iterations<br /> on the same kernel build.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/IOV: Skip VF Resizable BAR restore on read error<br /> <br /> sriov_restore_vf_rebar_state() uses the VF Resizable BAR Control register<br /> to decide how many VF BARs to restore (nbars) and which VF BAR each<br /> iteration addresses (bar_idx). bar_idx indexes into dev-&gt;sriov-&gt;barsz[],<br /> which has only PCI_SRIOV_NUM_BARS (6) entries.<br /> <br /> When a device does not respond, config reads typically return<br /> PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx<br /> both evaluate to 7. The barsz[] access then goes out of bounds. UBSAN<br /> reports this as:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51 index 7 is out of range for type &amp;#39;resource_size_t [6]&amp;#39;<br /> <br /> Observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that stopped responding<br /> during a failed GC6 power state exit. The subsequent pci_restore_state()<br /> invoked sriov_restore_vf_rebar_state() while config reads returned<br /> 0xffffffff, triggering the splat.<br /> <br /> Bail out if any VF Resizable BAR Control read returns PCI_ERROR_RESPONSE.<br /> No further VF BARs are touched, which is safe because a config read that<br /> returns PCI_ERROR_RESPONSE indicates the device is unreachable and<br /> restoration is pointless. This mirrors the guard in<br /> pci_restore_rebar_state().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpci_rt1711h: unregister TCPCI port with devres<br /> <br /> rt1711h_probe() registers the TCPCI port before requesting the interrupt<br /> and enabling alert interrupts. If either of those later steps fails, the<br /> probe function returns without unregistering the TCPCI port. The explicit<br /> unregister currently only happens from the remove callback.<br /> <br /> Register a devres action immediately after tcpci_register_port() succeeds,<br /> so tcpci_unregister_port() runs on later probe failures and on driver<br /> detach. Drop the remove callback to avoid unregistering the same port<br /> twice.<br /> <br /> This issue was identified during our ongoing static-analysis research while<br /> reviewing kernel code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix NULL pointer dereference in func_set_flag()<br /> <br /> func_set_flag() dereferences tr-&gt;current_trace_flags before verifying<br /> that the current tracer is actually the function tracer. When the active<br /> tracer has been switched away from "function" (e.g., to "wakeup_rt"),<br /> tr-&gt;current_trace_flags can be NULL, leading to a NULL pointer<br /> dereference and kernel crash.<br /> <br /> The call chain that triggers this is:<br /> <br /> trace_options_write()<br /> -&gt; __set_tracer_option()<br /> -&gt; trace-&gt;set_flag() /* func_set_flag */<br /> <br /> In func_set_flag(), the first operation is:<br /> <br /> if (!!set == !!(tr-&gt;current_trace_flags-&gt;val &amp; bit))<br /> <br /> This dereferences tr-&gt;current_trace_flags unconditionally. The safety<br /> check that guards against a non-function tracer:<br /> <br /> if (tr-&gt;current_trace != &amp;function_trace)<br /> return 0;<br /> <br /> is placed *after* the dereference, which is too late.<br /> <br /> This was observed with the following crash dump:<br /> <br /> BUG: unable to handle page fault at 0000000000000000<br /> RIP: func_set_flag+0xd<br /> <br /> Call Trace:<br /> __set_tracer_option+0x27<br /> trace_options_write+0x75<br /> vfs_write+0x12a<br /> ksys_write+0x66<br /> do_syscall_64+0x5b<br /> <br /> RIP: ffffffff914c973d RSP: ff67ec88b01dfdf0 RFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ff3a826e80354580 RCX: 0000000000000001<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff93918080<br /> <br /> The disassembly confirms the fault:<br /> <br /> func_set_flag+0: mov 0x1f08(%rdi), %rax ; RAX = tr-&gt;current_trace_flags = NULL<br /> func_set_flag+13: mov (%rax), %eax ; page fault: dereference NULL<br /> <br /> At the time of the crash:<br /> tr-&gt;current_trace_flags = 0x0 (NULL)<br /> tr-&gt;current_trace = wakeup_rt_tracer (not function_trace)<br /> <br /> The scenario is that a process opens a function tracer option file (such<br /> as "func_stack_trace"), then the current tracer is switched to another<br /> tracer (e.g., "wakeup_rt"), which sets current_trace_flags to NULL. When<br /> the process subsequently writes to the option file, func_set_flag() is<br /> invoked and crashes on the NULL dereference.<br /> <br /> Fix this by moving the current_trace check before the<br /> current_trace_flags dereference, so that func_set_flag() returns early<br /> when the function tracer is not active.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: misc: usbio: fix disconnect UAF in client teardown<br /> <br /> usbio_disconnect() walks usbio-&gt;cli_list in reverse and uninitializes each<br /> auxiliary device. auxiliary_device_uninit() drops the device reference, and<br /> for an unbound child that can run usbio_auxdev_release() and free the<br /> containing struct usbio_client.<br /> <br /> list_for_each_entry_reverse() advances after the loop body by reading<br /> client-&gt;link.prev. If the current client is freed by<br /> auxiliary_device_uninit(), the iterator dereferences freed memory.<br /> <br /> Use list_for_each_entry_safe_reverse() so the previous client is<br /> cached before the body can drop the final reference. This preserves<br /> reverse teardown order while keeping the next iterator cursor independent<br /> of the current client&amp;#39;s lifetime.<br /> <br /> Validation reproduced this kernel report:<br /> BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x66/0xa0<br /> print_report+0xce/0x630<br /> ? usbio_disconnect+0x12e/0x150<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __virt_addr_valid+0x188/0x320<br /> ? usbio_disconnect+0x12e/0x150<br /> kasan_report+0xe0/0x110<br /> ? usbio_disconnect+0x12e/0x150<br /> usbio_disconnect+0x12e/0x150<br /> usb_unbind_interface+0xf3/0x400<br /> really_probe+0x316/0x660<br /> __driver_probe_device+0x106/0x240<br /> driver_probe_device+0x4a/0x110<br /> __device_attach_driver+0xf1/0x1a0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> bus_for_each_drv+0xf9/0x160<br /> ? __pfx_bus_for_each_drv+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? trace_hardirqs_on+0x18/0x130<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? _raw_spin_unlock_irqrestore+0x44/0x60<br /> __device_attach+0x133/0x2a0<br /> ? __pfx___device_attach+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_raw_spin_unlock+0x9a/0x100<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> device_initial_probe+0x55/0x70<br /> bus_probe_device+0x4a/0xd0<br /> device_add+0x9b9/0xc10<br /> ? __pfx_device_add+0x10/0x10<br /> ? _raw_spin_unlock_irqrestore+0x44/0x60<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? lockdep_hardirqs_on_prepare+0xea/0x1a0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? usb_enable_lpm+0x3c/0x260<br /> usb_set_configuration+0xb64/0xf20<br /> usb_generic_driver_probe+0x5f/0x90<br /> usb_probe_device+0x71/0x1b0<br /> really_probe+0x46b/0x660<br /> __driver_probe_device+0x106/0x240<br /> driver_probe_device+0x4a/0x110<br /> __device_attach_driver+0xf1/0x1a0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> bus_for_each_drv+0xf9/0x160<br /> ? __pfx_bus_for_each_drv+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? trace_hardirqs_on+0x18/0x130<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? _raw_spin_unlock_irqrestore+0x44/0x60<br /> __device_attach+0x133/0x2a0<br /> ? __pfx___device_attach+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_raw_spin_unlock+0x9a/0x100<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> device_initial_probe+0x55/0x70<br /> bus_probe_device+0x4a/0xd0<br /> device_add+0x9b9/0xc10<br /> ? __pfx_device_add+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? add_device_randomness+0xb7/0xf0<br /> usb_new_device+0x492/0x870<br /> hub_event+0x1b10/0x29c0<br /> ? __pfx_hub_event+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? lock_acquire+0x187/0x300<br /> ? process_one_work+0x475/0xb90<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? lock_release+0xc8/0x290<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> process_one_work+0x4d7/0xb90<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __list_add_valid_or_report+0x37/0xf0<br /> ? __pfx_hub_event+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> worker_thread+0x2d8/0x570<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1ad/0x1f0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x3c9/0x540<br /> ? __pfx_ret_from_fork+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __switch_to+0x2e9/0x730<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: run gadget disconnect from sleepable suspend context<br /> <br /> dwc3_gadget_suspend() takes dwc-&gt;lock with IRQs disabled and then calls<br /> dwc3_disconnect_gadget(). For async callbacks that helper only uses<br /> plain spin_unlock()/spin_lock(), so the gadget -&gt;disconnect() callback<br /> still runs with IRQs disabled and any sleepable callback trips Lockdep.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the dwc3_gadget_suspend() -&gt;<br /> dwc3_disconnect_gadget() -&gt; gadget_driver-&gt;disconnect() chain, and<br /> Lockdep reported:<br /> <br /> BUG: sleeping function called from invalid context<br /> gadget_disconnect+0x21/0x39 [vuln_msv]<br /> dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv]<br /> <br /> Keep the disconnect callback selection in one common helper, but add a<br /> sleepable suspend-side wrapper which snapshots the callback under<br /> dwc-&gt;lock and then runs it after spin_unlock_irqrestore(). The regular<br /> event path still uses the existing spin_unlock()/spin_lock() window.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: chaoskey: Fix slab-use-after-free in chaoskey_release()<br /> <br /> The chaoskey driver has a use-after-free bug in its release routine.<br /> If the user closes the device file after the USB device has been<br /> unplugged, a debugging log statement will try to access the<br /> usb_interface structure after it has been deallocated:<br /> <br /> BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406)<br /> Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106<br /> <br /> Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)<br /> print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)<br /> kasan_report (mm/kasan/report.c:595)<br /> dev_driver_string (drivers/base/core.c:2406)<br /> __dynamic_dev_dbg (lib/dynamic_debug.c:906)<br /> chaoskey_release (drivers/usb/misc/chaoskey.c:323)<br /> __fput (fs/file_table.c:510)<br /> fput_close_sync (fs/file_table.c:615)<br /> __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> <br /> The driver&amp;#39;s last reference to the interface structure is dropped in<br /> the chaoskey_free() routine, so the code must not use the interface --<br /> even in a debugging statement -- after that routine returns.<br /> (Exception: If we know that another reference is held by someone else,<br /> such as the device core while the disconnect routine runs, there&amp;#39;s no<br /> problem. Thanks to Johan Hovold for pointing this out.)<br /> <br /> Since the bad access is part of an unimportant debugging statement,<br /> we can fix the problem simply by removing the whole statement.