Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer<br /> <br /> iscsi_tcp_hdr_dissect() receives the data segment of several PDU types<br /> into the fixed-size conn-&gt;data buffer, which is allocated for<br /> ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP,<br /> REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU<br /> whose DataSegmentLength exceeds that buffer.<br /> <br /> The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its<br /> data segment (sense/response data) into conn-&gt;data via<br /> iscsi_tcp_data_recv_prep(), but it does so without the same check. The<br /> only upstream bound on in.datalen is conn-&gt;max_recv_dlength, the<br /> initiator&amp;#39;s advertised MaxRecvDataSegmentLength, which is commonly<br /> negotiated well above 8192 (open-iscsi defaults to 262144). A target<br /> that returns a SCSI Response with a DataSegmentLength between 8193 and<br /> max_recv_dlength therefore overflows the 8192-byte conn-&gt;data buffer.<br /> <br /> Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly<br /> like those responses: bound the data segment, receive it into conn-&gt;data<br /> when present, and otherwise complete the PDU with no data. Fold the<br /> opcode into that case group rather than duplicating the check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer<br /> <br /> iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the<br /> target-supplied data segment. The segment carries a 2-byte sense length<br /> followed by the sense bytes, so it must hold 2 + senselen bytes, but the<br /> bounds check only requires datalen &gt;= senselen:<br /> <br /> senselen = get_unaligned_be16(data);<br /> if (datalen sense_buffer, data + 2,<br /> min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE));<br /> <br /> A target that returns a SCSI Response whose datalen equals senselen<br /> (with senselen data contents and end up in the command&amp;#39;s sense buffer, which is<br /> returned to userspace.<br /> <br /> Account for the 2-byte sense length prefix in the check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: reclaim invalid Tx descriptors in ZC batch path<br /> <br /> The zero-copy Tx batch parser stops when it encounters an invalid<br /> descriptor. If this happens after one or more continuation descriptors,<br /> the Tx consumer can be advanced past fragments that are neither submitted<br /> to the driver nor returned to userspace through the completion ring.<br /> <br /> A similar problem occurs when a packet exceeds xdp_zc_max_segs. The<br /> descriptors consumed up to the limit are released without completion, and<br /> the remaining continuation descriptors can subsequently be interpreted<br /> as the beginning of another packet.<br /> <br /> Parse Tx batches in packet units and distinguish descriptors belonging to<br /> complete valid packets from descriptors consumed while draining an<br /> invalid or oversized packet. Return the former to the driver and append<br /> the latter to the CQ address area so userspace can reclaim their UMEM<br /> frames.<br /> <br /> Treat a standalone invalid descriptor as a one-descriptor reclaim-only<br /> packet. Advancing the Tx-ring consumer releases the ring slot, but does<br /> not by itself return ownership of the referenced UMEM frame to userspace.<br /> <br /> Once draining starts, continue until the packet&amp;#39;s end-of-packet<br /> descriptor is consumed. Preserve the drain state on the socket when EOP<br /> has not yet been supplied, so draining can continue during a later call.<br /> Leave incomplete but otherwise valid packets on the Tx ring.<br /> <br /> Shared-UMEM pools using multi-buffer Tx also need packet-framed parsing.<br /> Walk their Tx sockets one packet at a time, preserving the existing<br /> per-socket fairness scheme, instead of using the legacy one-descriptor<br /> fallback. Keep that fallback for shared pools that do not use<br /> multi-buffer Tx. Since the drain state is maintained per socket and both<br /> the singular and shared paths can resume an interrupted drain, changing<br /> the socket list from singular to shared requires no special bind-time<br /> transition.<br /> <br /> CQ entries are positional, and drivers may complete only part of the Tx<br /> work returned by xsk_tx_peek_release_desc_batch(). Therefore, reclaim-only<br /> entries cannot be published immediately when earlier driver-visible<br /> descriptors are still outstanding.<br /> <br /> Track the number of driver-visible CQ entries preceding the reclaim<br /> entries. Let xsk_tx_completed() publish partial hardware Tx completions,<br /> and publish the reclaim entries only after every earlier Tx descriptor<br /> has completed. Complete a reclaim-only batch immediately when there is no<br /> driver-visible work in front of it, and prevent another Tx batch from<br /> being appended while reclaim entries remain pending.<br /> <br /> Also cap batch processing by the size of the pool&amp;#39;s temporary descriptor<br /> array, as Tx rings belonging to sockets sharing a UMEM may have different<br /> sizes.<br /> <br /> This ensures that every invalid Tx descriptor consumed by the ZC batch<br /> path is either submitted to the driver as part of a valid packet or<br /> returned to userspace without violating CQ completion ordering.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: drain continuation descs after overflow in xsk_build_skb()<br /> <br /> Fix generic xmit path multi-buffer logic when packets are either too big<br /> (count of descriptors exceed MAX_SKB_FRAGS) or an invalid descriptor is<br /> included in fragmented packet. Introduce xdp_sock::drain_cont and act<br /> upon this flag - when it is set, keep on consuming descriptors from<br /> AF_XDP Tx ring and put them directly onto Cq. Previously these<br /> descriptors were silently lost and could never be reached again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx<br /> <br /> This patch is inspired by the check[1] from sashiko. It says when<br /> overflow happens, the address of cq to be published is invalid.<br /> Actually the severer thing is the whole process of publishing the<br /> address of cq in this particular case is not right: it should truely<br /> publish the address and advance the cached_prod in cq as long as it<br /> reads descriptors from txq.<br /> <br /> The following is the full analysis.<br /> xsk_drop_skb() is called in three places, which all discard a partially<br /> built multi-buffer skb:<br /> 1) xsk_build_skb() -EOVERFLOW error path: packet exceeds MAX_SKB_FRAGS<br /> 2) __xsk_generic_xmit() post-loop cleanup: an invalid descriptor in<br /> the TX ring prevents the partial packet from completing<br /> 3) xsk_release(): socket close while xs-&gt;skb holds an incomplete packet<br /> <br /> In all three cases, the TX descriptors for the already-processed frags<br /> have been consumed from the TX ring (xskq_cons_release), and CQ slots<br /> have been reserved. However, xsk_drop_skb() calls xsk_consume_skb()<br /> which cancels the CQ reservations via xsk_cq_cancel_locked(). Since<br /> the buffer addresses never appear in the completion queue, userspace<br /> permanently loses track of these buffers.<br /> <br /> Fix this by letting consume_skb() trigger the existing xsk_destruct_skb<br /> destructor, which already submits buffer addresses to the CQ via<br /> xsk_cq_submit_addr_locked().<br /> <br /> Note that cancelling the descriptors back to the TX ring (via<br /> xskq_cons_cancel_n) is not a appropriate option because an oversized<br /> packet that always exceeds MAX_SKB_FRAGS would be retried indefinitely,<br /> which is an obviously deadlock bug in the TX path.<br /> <br /> Also move the desc-&gt;addr assignment in xsk_build_skb() above the<br /> overflow check so that the current descriptor&amp;#39;s address is recorded<br /> before a potential -EOVERFLOW jump to free_err, consistent with the<br /> zerocopy path in xsk_build_skb_zerocopy().<br /> <br /> [1]: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush<br /> <br /> nh_rt_cache_flush() walks nh-&gt;f6i_list during an RTNL-serialized nexthop<br /> replace without holding nh-&gt;lock, racing the unlocked IPv6 route<br /> add/delete that mutate the list under nh-&gt;lock and free fib6_info<br /> entries (nh_rt_cache_flush() is inlined into rtm_new_nexthop()):<br /> <br /> BUG: KASAN: slab-use-after-free in nh_rt_cache_flush (net/ipv4/nexthop.c:2243)<br /> Read of size 8 at addr ffff888012953e18 by task exploit/146<br /> nh_rt_cache_flush (net/ipv4/nexthop.c:2243)<br /> replace_nexthop (net/ipv4/nexthop.c:2610)<br /> rtm_new_nexthop (net/ipv4/nexthop.c:3323)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)<br /> <br /> Unlike the other f6i_list walks, this one bumps each route&amp;#39;s sernum via<br /> fib6_update_sernum_upto_root(), which needs tb6_lock; taking nh-&gt;lock<br /> around it would invert the established tb6_lock -&gt; nh-&gt;lock order and<br /> deadlock. As the only purpose is to invalidate cached dsts, bump the<br /> IPv6 sernum for the whole netns with rt_genid_bump_ipv6() instead,<br /> mirroring the rt_cache_flush() already done for IPv4 just above.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: take nh-&gt;lock for f6i_list walks in replace check and notify<br /> <br /> fib6_check_nh_list() and __nexthop_replace_notify() walk nh-&gt;f6i_list<br /> during an RTNL-serialized nexthop replace without holding nh-&gt;lock. IPv6<br /> RTM_NEWROUTE/RTM_DELROUTE run without RTNL and mutate that list under<br /> nh-&gt;lock (fib6_add_rt2node_nh(), fib6_purge_rt()), so both walks race a<br /> concurrent route delete that unlinks and frees a fib6_info:<br /> <br /> BUG: KASAN: slab-use-after-free in rt6_fill_node.isra.0 (net/ipv6/route.c:5799)<br /> Read of size 4 at addr ffff888014607e64 by task exploit/143<br /> rt6_fill_node.isra.0 (net/ipv6/route.c:5799)<br /> fib6_rt_update (net/ipv6/route.c:6412)<br /> __nexthop_replace_notify (net/ipv4/nexthop.c:2542)<br /> rtm_new_nexthop (net/ipv4/nexthop.c:2554)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)<br /> <br /> BUG: KASAN: slab-use-after-free in fib6_check_nh_list (net/ipv4/nexthop.c:1605)<br /> Read of size 8 at addr ffff888014a7d068 by task exploit/142<br /> fib6_check_nh_list (net/ipv4/nexthop.c:1605)<br /> rtm_new_nexthop (net/ipv4/nexthop.c:2575)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)<br /> <br /> Both walks only read the entries and take no tb6_lock, so protect them<br /> with nh-&gt;lock; fib6_rt_update() uses gfp_any(), which returns GFP_ATOMIC<br /> under the lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check()<br /> <br /> rds_tcp_laddr_check() looks up a scoped IPv6 interface with<br /> dev_get_by_index_rcu(), drops the RCU read-side lock, and only then<br /> passes the bare struct net_device * into ipv6_chk_addr().<br /> <br /> dev_get_by_index_rcu() only keeps the device alive within the same RCU<br /> read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can<br /> free the net_device; ipv6_chk_addr() then dereferences the stale pointer<br /> in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading<br /> freed memory.<br /> <br /> Keep the RCU read-side lock held across the ipv6_chk_addr() call instead<br /> of dropping it right after the lookup, so the device cannot be freed<br /> while it is in use.<br /> <br /> BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998)<br /> Read of size 8 at addr ffff8880106ec000 by task exploit/153<br /> Call Trace:<br /> ...<br /> kasan_report (mm/kasan/report.c:595)<br /> __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998)<br /> ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972)<br /> rds_tcp_laddr_check (net/rds/tcp.c:370)<br /> rds_bind (net/rds/bind.c:248)<br /> __sys_bind (net/socket.c:1920)<br /> __x64_sys_bind (net/socket.c:1956)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH<br /> <br /> The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the<br /> dsthash_ent structure which represents an entry in the hashtable. There<br /> is a union area which uses a different layout to express the rate match<br /> mode.<br /> <br /> Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode<br /> flag is requested by two or more different rules that refer to the same<br /> hashtable. Otherwise, uninitialized access to the burst field in the<br /> union is possible.<br /> <br /> Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by<br /> revision less than 3 too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread<br /> <br /> When userspace configures &amp;#39;auto_update_interval&amp;#39; to 0 via sysfs, the<br /> background kthread executes schedule_timeout_interruptible(0), which<br /> returns immediately.<br /> <br /> If &amp;#39;num_temp_sensors&amp;#39; is concurrently or previously set to 0, the<br /> msleep_interruptible() delay inside adt7470_read_temperatures() also<br /> becomes 0. This combination forces the background thread into a tight,<br /> unbounded busy-loop, hogging the CPU and flooding the I2C bus with a<br /> continuous stream of transactions.<br /> <br /> Fix this vulnerability by raising the lower limit of the clamp_val in<br /> auto_update_interval_store() from 0 to 500 milliseconds. This guarantees<br /> a reasonable minimum sleep window between sensor updates, protecting the<br /> system from intentional or accidental I2C bus denial of service.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> forcedeth: fix UAF of txrx_stats in nv_remove<br /> <br /> nv_remove() frees the per-CPU txrx_stats before unregister_netdev().<br /> Until unregister completes, ndo_get_stats64, the NAPI/xmit data path,<br /> and nv_close()/drain may still access txrx_stats, leading to a<br /> use-after-free.<br /> <br /> Free the stats only after unregister_netdev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (nct6775-core) Prevent access to unsupported weight registers<br /> <br /> Sashiko reports:<br /> <br /> During initialization of the nct6116 chip, the driver sets data-&gt;pwm_num<br /> to 5. However, it assigns several NCT6106 register arrays (such as<br /> NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and<br /> NCT6106_REG_WEIGHT_TEMP_*) to data-&gt;REG_PWM and data-&gt;REG_WEIGHT_TEMP.<br /> These arrays only contain 3 elements.<br /> <br /> In nct6775_update_pwm(), the driver iterates up to data-&gt;pwm_num. If<br /> data-&gt;has_pwm has bits 3 or 4 set (which is structurally possible for<br /> nct6116), the loop attempts to read elements at index 3 and 4 from these<br /> 3-element arrays. This results in a global out-of-bounds read, which can<br /> be caught by KASAN.<br /> <br /> Furthermore, the driver uses these garbage out-of-bounds values as<br /> hardware register addresses for subsequent read and write operations. This<br /> leads to invalid hardware register access, potentially causing hardware<br /> misconfiguration or system crashes.<br /> <br /> The underlying problem is that the chip does support up to five fan<br /> control channels, but only the first three support weight control.<br /> Fix the problem by extending the affected weight register arrays with<br /> zeroed fields. The driver uses zeroed register addresses to determine<br /> if a register is supported or not, and skips accesses for unsupported<br /> registers.