Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: thunderbolt: Tear down DMA paths before stopping the rings<br /> <br /> tbnet_tear_down() stops both rings and frees their frame buffers before<br /> calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring&amp;#39;s<br /> descriptor base and tbnet_free_buffers() unmaps and frees the pages the<br /> frames sit in, so by the time __tb_path_deactivate_hop() polls the hop&amp;#39;s<br /> &amp;#39;pending&amp;#39; bit, anything still in flight has nowhere to drain to.<br /> <br /> The teardown sequence has been in this order since the driver was added.<br /> The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable<br /> DMA paths only after rings are enabled") moved the path enable to the end<br /> of tbnet_connected_work() and documented why:<br /> <br /> /* Both logins successful so enable the rings, high-speed DMA<br /> * paths and start the network device queue.<br /> *<br /> * Note we enable the DMA paths last to make sure we have primed<br /> * the Rx ring before any incoming packets are allowed to<br /> * arrive.<br /> */<br /> <br /> Teardown was never updated to match, so the rings and the paths now come<br /> down in the same order they go up instead of in reverse.<br /> <br /> On an ASMedia ASM4242 host router the &amp;#39;pending&amp;#39; bit then never clears:<br /> every teardown burns the full 500 ms timeout and<br /> __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to<br /> 5 s does not help, so the hop is not slow to drain, it never drains<br /> at all.<br /> <br /> The failure is invisible above the thunderbolt core.<br /> __tb_path_deactivate_hops() is void and only calls tb_port_warn();<br /> tb_path_deactivate(), tb_tunnel_deactivate() and<br /> __tb_disconnect_xdomain_paths() are void as well, and<br /> tb_disconnect_xdomain_paths() ends in an unconditional "return 0". So<br /> tb_xdomain_disable_paths() reports success and the netdev_warn() below<br /> it never fires. Repeated teardowns eventually take the XDomain control<br /> channel down, after which the peer node is gone and only a power cycle<br /> brings the controller back.<br /> <br /> Deactivating the paths first fixes it. Measured with kretprobes on a<br /> stock v6.17 tree with no other patches applied, on a link that was up<br /> and had just carried traffic:<br /> <br /> before: __tb_path_deactivate_hop() returns 0 for the first hop, then<br /> -ETIMEDOUT for the second 500335 us later<br /> after: 0 for both, 525 us apart<br /> <br /> Alternating the two orderings ABBA over three load levels, four<br /> teardowns per arm: every teardown failed before the change (21 of 21<br /> that ran), none failed after (0 of 24). The before arms ran short<br /> because the link died partway through. The same split shows up when<br /> the interface is enslaved to a bond instead of just brought down, which<br /> is how I ran into this in the first place. Throughput and latency after<br /> the change are unchanged.<br /> <br /> Hosts whose routers drain the hop despite the stale descriptor base see<br /> no functional difference, since the paths end up deactivated either way.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix TOCTOU race between smc_listen_out() and listener close<br /> <br /> smc_listen_out() reads lsmc-&gt;sk.sk_state without the listener lock,<br /> then acquires lock_sock_nested() only after the check passes. This<br /> opens a window where smc_close_active() can transition the listener<br /> to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept<br /> queue, and release the lock, all between the lockless read and the<br /> delayed lock acquisition:<br /> <br /> smc_listen_work (smc_hs_wq) smc_close_active()<br /> ------------------------------- -------------------------<br /> release_sock(child)<br /> if (sk_state == SMC_LISTEN) TRUE<br /> lock_sock(listener)<br /> sk_state = SMC_CLOSED<br /> smc_close_cleanup_listen()<br /> release_sock(listener)<br /> flush_work(tcp_listen_work)<br /> lock_sock_nested(listener)<br /> smc_accept_enqueue(listener, child) /* child enqueued on dead listener */<br /> <br /> smc_close_active() flushes only tcp_listen_work. Work items already<br /> dispatched onto smc_hs_wq for the CLC handshake continue running<br /> unguarded. smc_accept_enqueue() takes a sock_hold() on the child that<br /> is never released, so the child smc_sock, its clcsock, and the<br /> reference all leak. A remote peer that opens TCP connections while the<br /> server calls close() can exhaust kernel memory.<br /> <br /> Move lock_sock_nested() to before the sk_state check so that the test<br /> and the enqueue are atomic under the listener lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: prestera: validate firmware header length<br /> <br /> prestera_fw_hdr_parse() reads the firmware header before checking<br /> that the firmware image contains that header.<br /> <br /> Reject images shorter than struct prestera_fw_header before decoding the<br /> magic and version fields.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length<br /> <br /> ncsi_send_cmd_nl() takes the number of bytes to copy from the<br /> attacker-controlled ncsi_pkt_hdr.length field of the in-band packet<br /> header, while the source buffer is the NCSI_ATTR_DATA netlink<br /> attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr).<br /> The two length sources are never cross-checked: only<br /> nla_len() &gt;= sizeof(struct ncsi_pkt_hdr) is enforced.<br /> <br /> With hdr-&gt;length set larger than the attribute payload (up to 65535<br /> against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies<br /> past the end of the netlink attribute buffer with unsafe_memcpy(),<br /> leaking up to ~64KB of kernel heap memory into the transmitted NCSI<br /> command packet. The destination skb is sized by the declared payload,<br /> so the write side does not overflow - this is a pure OOB read /<br /> information leak, reachable with CAP_NET_ADMIN on systems with a<br /> registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where<br /> NET_NCSI=y is standard).<br /> <br /> Reject commands whose declared payload extends past the end of the<br /> data attribute.<br /> <br /> The issue was found by the autokbug dynamic kernel fuzzer at Tencent<br /> Yunding Lab.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: Use unsigned int for ndp_index<br /> <br /> The variable ndp_index is declared as a signed integer, but it stores<br /> the return value of get_ncm(), which is unsigned.<br /> <br /> A malicious host can supply a large offset that overflows the signed<br /> ndp_index, making it negative. Because ndp_index is compared against<br /> unsigned bounds, this negative value bypasses sanity checks and leads<br /> to an out-of-bounds read when calculating the address of the NDP<br /> block (ntb_ptr + ndp_index).<br /> <br /> Fix this by changing ndp_index to unsigned int to ensure consistent<br /> unsigned comparisons throughout the function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()<br /> <br /> If cxacru_cm() encounters an error while submitting or waiting for snd_urb,<br /> it aborts and returns the error without killing the already submitted<br /> rcv_urb. This leaves the rcv_urb active.<br /> <br /> When this happens during initialization (e.g., in cxacru_atm_start()), the<br /> driver may ignore the error and proceed to call cxacru_poll_status(), which<br /> invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb<br /> triggers a warning in usb_submit_urb():<br /> <br /> cxacru 1-1:1.0: send of cm 0x84 failed (-104)<br /> ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104<br /> ------------[ cut here ]------------<br /> URB ffff88812658d200 submitted while active<br /> WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0<br /> drivers/usb/core/urb.c:379<br /> ...<br /> Call Trace:<br /> <br /> cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631<br /> cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline]<br /> cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828<br /> cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814<br /> usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927<br /> usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178<br /> cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370<br /> ...<br /> <br /> To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts<br /> early. We can safely call usb_kill_urb() on rcv_urb in the error path, as<br /> it is safe to call even if the URB is not active (e.g., if it failed to<br /> submit in the first place, or if it already completed).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msg<br /> <br /> ibuf_len is the bulk IN (receive) buffer size, but the EMSGSIZE check<br /> in usbio_bulk_msg() compares it against txbuf_len — the bulk OUT<br /> endpoint size. Both are taken independently from different endpoints<br /> in usbio_probe(), so the check is wrong when they differ.<br /> <br /> Use rxbuf_len for the IN direction. This matches the buffer that<br /> actually holds the response data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: fix OOB write on Type II inbound URBs<br /> <br /> data_ep_set_params() sizes each URB transfer buffer before it adds the<br /> Format Type II transfer delimiter:<br /> <br /> u-&gt;packets = urb_packs;<br /> u-&gt;buffer_size = maxsize * u-&gt;packets;<br /> <br /> if (fmt-&gt;fmt_type == UAC_FORMAT_TYPE_II)<br /> u-&gt;packets++; /* for transfer delimiter */<br /> u-&gt;urb = usb_alloc_urb(u-&gt;packets, GFP_KERNEL);<br /> <br /> buffer_size is computed from the pre-increment packet count and never<br /> recomputed, so for a Type II endpoint the buffer is one packet short of<br /> the packet count the URB is built with.<br /> <br /> prepare_inbound_urb() then lays out one iso frame per packet and never<br /> consults buffer_size:<br /> <br /> offs = 0;<br /> for (i = 0; i packets; i++) {<br /> urb-&gt;iso_frame_desc[i].offset = offs;<br /> urb-&gt;iso_frame_desc[i].length = ep-&gt;curpacksize;<br /> offs += ep-&gt;curpacksize;<br /> }<br /> <br /> urb-&gt;transfer_buffer_length = offs;<br /> urb-&gt;number_of_packets = urb_ctx-&gt;packets;<br /> <br /> The last descriptor therefore points one packet past the end of the<br /> transfer buffer, where the host controller writes device data on every<br /> inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound<br /> their fill loops by ctx-&gt;buffer_size, so only capture is affected.<br /> <br /> fmt_type comes from the device&amp;#39;s audio streaming descriptors, so any<br /> device advertising a Type II capture format hits this once userspace sets<br /> hw_params on the stream.<br /> <br /> KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report<br /> per inbound transfer:<br /> <br /> BUG: KASAN: slab-out-of-bounds in dummy_timer<br /> Write of size 64 at addr ffff0000186171c0 by task cons02/166<br /> __asan_memcpy<br /> dummy_timer<br /> hrtimer_run_softirq<br /> Allocated by task 166:<br /> usb_alloc_coherent<br /> snd_usb_endpoint_set_params<br /> The buggy address is located 0 bytes to the right of<br /> allocated 64-byte region [ffff000018617180, ffff0000186171c0)<br /> <br /> Compute buffer_size after the delimiter packet has been accounted for,<br /> and bound the fill loop by buffer_size, as prepare_silent_urb() already<br /> does on the outbound side. This grows every Type II URB allocation by<br /> one maxsize packet.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: evdev - sanitize event type index when fetching event masks<br /> <br /> The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK<br /> ioctls is used to index the static counts array in evdev_get_mask_cnt()<br /> and client evmasks array in evdev_get_mask().<br /> <br /> While the event type is architecturally bounded by EV_CNT, speculative<br /> execution may mispredict bounds checks and perform out-of-bounds loads.<br /> <br /> Sanitize the event type index in evdev_get_mask_cnt() branchlessly using<br /> array_index_mask_nospec(). This clamps the index to 0 for safe array<br /> access and forces the returned count to 0 speculatively when the index<br /> is out of bounds.<br /> <br /> We do not need additional array_index_nospec() calls in evdev_get_mask()<br /> because evdev_get_mask_cnt() speculatively forces the count (and<br /> resulting xfer_size) to 0 for out-of-bounds types, preventing any<br /> speculative memory access to client evmasks array.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tap: set skb-&gt;dev before parsing virtio net header in tap_get_user_xdp()<br /> <br /> The commit 4f61f133f354 ("net: tap: NULL pointer derefence in<br /> dev_parse_header_protocol when skb-&gt;dev is null") fixed a crash in<br /> tap_get_user() by assigning skb-&gt;dev before calling tun_vnet_hdr_to_skb().<br /> This is required because virtio_net_hdr_to_skb() may invoke<br /> dev_parse_header_protocol(), which dereferences skb-&gt;dev. Without the<br /> assignment, a NULL pointer dereference can occur.<br /> <br /> However, tap_get_user_xdp() still parses the virtio-net header before<br /> assigning skb-&gt;dev. When the vhost TX path passes an XDP buffer containing<br /> a GSO virtio-net header but the protocol is set to zero on purpose,<br /> tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb-&gt;dev<br /> is still NULL, resulting in a crash.<br /> <br /> Fix this by looking up the tap device and assigning skb-&gt;dev before calling<br /> tun_vnet_hdr_to_skb(), matching the ordering already used in<br /> tap_get_user(). Preserve the existing RCU read-side critical section across<br /> dev_queue_xmit().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (ltc4282) Clamp negative current limits<br /> <br /> When a negative value is passed to ltc4282_write_curr(), the signed long<br /> val is cast directly to u64:<br /> <br /> drivers/hwmon/ltc4282.c:ltc4282_write_curr() {<br /> /* need to pass it in millivolt */<br /> u32 in = DIV_ROUND_CLOSEST_ULL((u64)val * st-&gt;rsense, DECA * MICRO);<br /> ...<br /> }<br /> <br /> This cast converts negative inputs into large positive values. The<br /> subsequent division result overflows the u32 in variable, truncating<br /> to a pseudo-random positive value. When this is passed to<br /> ltc4282_write_voltage_byte(), it is clamped to the maximum limit instead<br /> of zero.<br /> <br /> Clamp val to 0 and to the maximum supported upper limit before the cast<br /> and assign the result to a 64-bit temporary variable before the division<br /> to avoid the underflow and an also possible overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rqspinlock: Reset tail when preserving queue on deadlock<br /> <br /> Currently, the destruction of the waiter queue is suppressed for<br /> rqspinlock in cases where a deadlock is detected. Deadlock checks happen<br /> relatively frequently (on entry for AA, within 1ms for ABBA), and waiter<br /> threads may not be involved in locking scenarios involving deadlocks.<br /> Thus, it is useful to not flush the queue and let other waiters take a<br /> stab at acquiring the lock after we detect a deadlock and exit.<br /> <br /> However, we need to follow the same logic as what we did previously for<br /> the waitq_timeout label: reset the tail, and if we cannot, signal the<br /> next waiter appropriately. In case of deadlocks, this signal would just<br /> mark the MCS node as unlocked, and in case of timeouts, it would signal<br /> RES_TIMEOUT_VAL. The difference thus is in the value propagated, which<br /> decides whether the queue remains active or gets flushed.<br /> <br /> Not doing the tail reset, and waiting for the next waiter can lead to<br /> cases where we are the final waiter, and thus no next waiter arrives,<br /> leading to intermittent stalls in this path. Once the next waiter does<br /> join, we will be unblocked. In the theoretical case when the next waiter<br /> never joins, we risk stalling indefinitely.<br /> <br /> This can only happen for ABBA deadlocks, since entry into the wait queue<br /> is guarded with AA checks. A precise sequence of executions leading up<br /> to this scenario can be:<br /> <br /> CPU 0 holds lock A.<br /> CPU 1 holds lock B.<br /> CPU 2 attempts lock B, becomes the pending waiter for B.<br /> CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues.<br /> CPU 1 attempts lock A.<br /> CPU 0 detects an ABBA deadlock.<br /> <br /> Once deadlock detection happens for CPU 0, it will sit waiting for the<br /> next waiter in the queue to populate node-&gt;next, which will experience<br /> delays until such a waiter arrives.<br /> <br /> Fix this by adjusting the logic for the check for deadlocks preceding<br /> the waitq_timeout label. It would make sense to consolidate code for<br /> both cases and use &amp;#39;ret&amp;#39; to distinguish the value being propagated, but<br /> that is left as an exercise for a future refactoring task to avoid diff<br /> noise in this patch.