Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-scsi: reject feature changes after endpoint<br /> <br /> vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates<br /> each command&amp;#39;s protection scatterlist array (prot_sgl) according to the<br /> acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt<br /> when VHOST_SET_FEATURES changes that bit later.<br /> <br /> Although virtio feature bits must not change after feature negotiation,<br /> vhost_scsi_set_features() currently accepts such a request after the<br /> endpoint is active and updates acked_features. Enabling T10-PI after<br /> endpoint setup therefore leaves prot_sgl NULL while the I/O path follows<br /> the new feature bit.<br /> <br /> For a 129-page protection payload, vhost_scsi_mapal() passes the missing<br /> first chunk to sg_alloc_table_chained():<br /> <br /> sg_alloc_table_chained(table, 129, first_chunk=NULL,<br /> nents_first_chunk=inline_sg_cnt)<br /> <br /> sg_pool_index() then hits:<br /> <br /> BUG_ON(nents &gt; SG_CHUNK_SIZE); /* 129 &gt; 128 */<br /> <br /> The kernel reported the following call trace and register state:<br /> <br /> Call Trace:<br /> <br /> ? __sg_alloc_table+0x1d8/0x250<br /> ? __pfx_vhost_run_work_list+0x10/0x10 [vhost]<br /> sg_alloc_table_chained+0x59/0xf0<br /> ? __pfx_sg_pool_alloc+0x10/0x10<br /> ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi]<br /> vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi]<br /> ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi]<br /> vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi]<br /> vhost_run_work_list+0x8e/0xd0 [vhost]<br /> vhost_task_fn+0xe1/0x210<br /> ret_from_fork+0x348/0x540<br /> <br /> <br /> RIP: 0010:0x4<br /> CR2 = 0x4<br /> RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202<br /> RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081<br /> <br /> VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only<br /> exception.<br /> <br /> Reject changes to any feature other than VHOST_F_LOG_ALL while the<br /> endpoint is active. This preserves the existing runtime log toggle while<br /> preventing feature-dependent command resources and data-path state from<br /> becoming inconsistent. Userspace must clear the endpoint before changing<br /> any other negotiated feature and set the endpoint up again afterward.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-scsi: Validate T10 PI scatterlist counts<br /> <br /> When T10 PI is negotiated, vhost-scsi splits protection bytes from<br /> the data iterator before mapping the request scatterlists. A malformed<br /> request can claim protection bytes that cover or exceed the full payload<br /> length. The former leaves no data bytes to map, while the latter<br /> underflows exp_data_len before advancing the iterator. Both cases can let<br /> a zero data SGL count reach sg_alloc_table_chained(), which triggers<br /> BUG_ON(!nents).<br /> <br /> Reject protection lengths that cover or exceed the payload before<br /> subtracting prot_bytes and advancing the iterator. Also propagate<br /> negative errors from the protection SGL calculation before calling the<br /> allocator, matching the data SGL path.

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