Vulnerabilidades

*** 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 /> watchdog: at91sam9_wdt: prevent timer rearm during teardown<br /> <br /> at91_ping() rearms the watchdog timer from its callback. timer_delete()<br /> neither waits for a running callback nor prevents it from rearming the<br /> timer, so probe failure or driver removal can leave the timer accessing the<br /> devm-allocated at91wdt after it has been freed.<br /> <br /> Use timer_shutdown_sync() on both teardown paths. It waits for a running<br /> callback and rejects any attempt by the callback to rearm the timer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: clear control chunk transport if it is being removed<br /> <br /> sctp_make_heartbeat_ack() caches the destination transport in<br /> chunk-&gt;transport without taking a reference. When src_out_of_asoc_ok is<br /> enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead<br /> of being transmitted immediately.<br /> <br /> If the peer transport is removed while the chunk is still queued,<br /> sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing,<br /> but only clears cached transport pointers in out_chunk_list. The queued<br /> control chunk therefore retains a dangling transport pointer.<br /> <br /> Once an ASCONF_ACK clears the suppression and the queued control chunk is<br /> transmitted, SCTP dereferences the stale transport pointer, leading to a<br /> use-after-free.<br /> <br /> Fix this by also clearing chunk-&gt;transport for queued control chunks in<br /> control_chunk_list when removing the transport.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/atm: fix slab-out-of-bounds read in vcc_setsockopt()<br /> <br /> vcc_setsockopt() contained an ineffective optlen check:<br /> if (__SO_LEVEL_MATCH(optname, level) &amp;&amp; optlen != __SO_SIZE(optname))<br /> return -EINVAL;<br /> <br /> If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller<br /> passed a mismatched level), the length check optlen != __SO_SIZE(optname)<br /> was short-circuited and bypassed. Execution then fell through to switch(optname),<br /> calling copy_from_sockptr() assuming optval contained sufficient space.<br /> <br /> Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink<br /> optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(),<br /> this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the<br /> expected structure size.<br /> <br /> Fix this by using copy_safe_from_sockptr(), which unconditionally validates<br /> that optlen is at least the expected size before copying. Also change the local<br /> &amp;#39;value&amp;#39; variable type from &amp;#39;unsigned long&amp;#39; to &amp;#39;int&amp;#39; so that SO_SETCLP matches<br /> its sizeof(int) ABI encoding on 64-bit systems.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ism: Fix UAF of sba and ieq during ism_dev_exit()<br /> <br /> A ism interrupt handler can be active in parallel with ism_dev_exit(),<br /> accessing freed data structures.<br /> <br /> No new interrupts will be generated after unregister_ieq(). Drain ongoing<br /> interrupt handlers by free_irq(), before freeing ism data structures.

*** 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 /> 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 /> 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.