Vulnerabilidades

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

*** 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 /> ima: fix out-of-bounds read in xattr_verify()<br /> <br /> The digest-length check in xattr_verify() mixes int and size_t:<br /> <br /> if (xattr_len - sizeof(xattr_value-&gt;type) - hash_start &gt;=<br /> iint-&gt;ima_hash-&gt;length)<br /> <br /> sizeof() yields size_t, so the usual arithmetic conversions promote<br /> the whole left-hand side to unsigned 64-bit before the subtraction<br /> runs. For a truncated xattr this underflows instead of going negative:<br /> a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1)<br /> turns "1 - 1 - 1" into SIZE_MAX, which is trivially &gt;= ima_hash-&gt;length.<br /> The check then passes and the following memcmp() reads<br /> iint-&gt;ima_hash-&gt;length bytes starting past the end of the buffer<br /> vfs_getxattr_alloc() allocated for it.<br /> <br /> Nothing upstream clamps xattr_len back into a safe range first:<br /> ima_get_hash_algo() only special-cases xattr_len

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: evdev - fix information leak in evdev_pass_values()<br /> <br /> In evdev_pass_values(), the input_event structure is allocated on the<br /> kernel stack and populated field-by-field. However, it is never fully<br /> initialized. On architectures where struct input_event contains explicit<br /> or implicit padding (such as the 32-bit __pad field on SPARC64), these<br /> padding bytes are left uninitialized.<br /> <br /> When this event structure is subsequently passed to the client buffer<br /> and later copied to userspace, the uninitialized padding bytes leak<br /> kernel stack memory, potentially exposing sensitive information.<br /> <br /> Similar issues exist in __evdev_queue_syn_dropped and __pass_event.<br /> <br /> Fix this by explicitly zeroing the entire event structure with memset()<br /> before populating its fields. This ensures all padding bytes are cleared<br /> before the data crosses the security boundary.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix incorrect flush address in direct page table reclaim<br /> <br /> When zap_pte_range reclaims a page table, it does:<br /> <br /> pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);<br /> <br /> and this is unconditionally wrong: if this code executes, addr *always*<br /> points one past the end of the range covered by the table. The addr<br /> parameter is used to flush the TLB (really the paging-structure-cache)<br /> to drop references to the to-be-freed table, and any architecture that<br /> cares about the parameter will flush the wrong address. (But they&amp;#39;ll<br /> still free the correct page).<br /> <br /> I think it&amp;#39;s worth contemplating why the kernel works at all.<br /> <br /> If we hit the offending line of code, we will first clear the PMD entry<br /> (line 1954, zap_empty_pte_table), then we will issue pending flushes if<br /> force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the<br /> retry on line 1979 (phew!), and then we will do the offending<br /> pte_free_tlb call. *Or* we will clear the PMD entry immediately before<br /> pte_free_tlb (line 1983, zap_pte_table_if_empty).<br /> <br /> If we have any pending flushes (i.e. we actually zapped any last-level<br /> entries) at the time we clear the PMD entry, then the flush really ought<br /> to flush all references to the table (Linus certainly seems to think it<br /> will on all architectures [0]).<br /> <br /> The condition under which we have no accumulated flushes at the time of<br /> the clear is very complex (the whole zap_pte_range function has absurdly<br /> complex control flow). If we do hit the bad case, then we will end up<br /> clearing the PMD entry after the last time the range is flushed, and any<br /> CPU is free to cache a reference to the (empty) page table. If this<br /> happens due to an ordinary read or write, it would segfault, so it would<br /> be rare. But the cache could be speculatively filled as well. Then<br /> we&amp;#39;ll flush the wrong address and then free and possibly reuse the<br /> table.<br /> <br /> On x86, even flushing the wrong address works on non-KPTI Intel systems<br /> because INVLPG flushes *all* paging-structure-caches, not just the ones<br /> for the target address. But INVPCID does not, and flush_tlb_one_user<br /> will use INVPCID if it&amp;#39;s available. And then we&amp;#39;re toast. AMD systems<br /> are more susceptible: we set the EFER.TCE bit, which makes even INVLPG<br /> only flush the target address.<br /> <br /> I think this might fix an issue in ripgrep reported here:<br /> https://github.com/BurntSushi/ripgrep/issues/3494<br /> <br /> [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: stabilize tty reference in kbd_keycode with tty_port_tty_get<br /> <br /> kbd_keycode() reads vc-&gt;port.tty without acquiring a tty reference,<br /> racing against con_shutdown() which clears port.tty under a different<br /> lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference<br /> for the duration the tty pointer is needed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: add permission check for KDSKBMETA ioctl<br /> <br /> KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all<br /> other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process<br /> to change meta mode on a non-controlling console without authorization.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: ipheth: fix carrier_work UAF on disconnect<br /> <br /> ipheth_sndbulk_callback() re-arms the carrier-check work on any<br /> non-zero URB status:<br /> <br /> else<br /> schedule_delayed_work(&amp;dev-&gt;carrier_work, 0);<br /> <br /> Nothing ties that to the interface being up, so the work can be armed<br /> again after ipheth_close() has already drained it, and stay armed<br /> until the netdev whose private area embeds it is freed.<br /> <br /> On unplug with a TX URB in flight, ipheth_disconnect() drains the work<br /> through unregister_netdev() -&gt; ipheth_close() -&gt;<br /> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs().<br /> usb_kill_urb() completes the in-flight TX URB with -ENOENT, so<br /> ipheth_sndbulk_callback() runs after the drain and re-arms<br /> carrier_work.<br /> <br /> The same completion also re-arms the work if the interface is only<br /> brought down while a TX URB is in flight, and<br /> ipheth_carrier_check_work() then keeps re-queueing itself once a<br /> second. unregister_netdev() does not call ipheth_close() for an<br /> already-down interface, so nothing drains it on the later unplug<br /> either.<br /> <br /> In both cases free_netdev() frees the netdev while carrier_work is<br /> still pending, and ipheth_carrier_check_work() dereferences freed<br /> memory.<br /> <br /> Tie the work to the interface state instead of chasing the completion:<br /> disable it in ipheth_close() and enable it in ipheth_open(), so a<br /> schedule_delayed_work() from the URB completion is a no-op whenever<br /> the interface is not up. disable_delayed_work_sync() also waits for a<br /> running instance, so it fully replaces the cancel_delayed_work_sync()<br /> it takes the place of. The work starts out disabled in ipheth_probe()<br /> so the enable/disable counts balance from the first open.<br /> <br /> Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and<br /> raw-gadget standing in for the device, driving the second path above (the<br /> interface is already down, so unregister_netdev() does not call<br /> ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in<br /> __run_timers(), freed by ipheth_disconnect() and re-armed from<br /> ipheth_sndbulk_callback() via queue_delayed_work_on(). The<br /> same trigger on a kernel differing only by this patch reports 0 of 15,<br /> and the carrier check still functions across open/close cycles.<br /> <br /> The reproducer needs an attached USB device that stops draining bulk OUT,<br /> plus a link down and unplug, driven as root. It is not a privilege<br /> boundary crossing and no exploit primitive was developed.<br /> <br /> Found by 0sec (https://0sec.ai).