Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: refuse to enslave CAN devices<br /> <br /> syzbot reported a kernel paging request crash in<br /> can_rx_unregister() inside net/can/af_can.c. The crash occurs<br /> because a virtual CAN device (vxcan) is being enslaved to a<br /> bonding master.<br /> <br /> During the enslavement process, the bonding driver mutates<br /> and modifies the network device states to fit an Ethernet-like<br /> aggregation model. However, CAN devices operate on a completely<br /> different Layer 2 architecture, relying on the CAN mid-layer<br /> private data structure (can_ml_priv) instead of standard<br /> Ethernet structures. Since bonding does not initialize or<br /> maintain these CAN structures, subsequent operations on the<br /> half-enslaved interface (such as closing associated sockets<br /> via isotp_release) lead to a null-pointer dereference when<br /> accessing the CAN receiver lists.<br /> <br /> Bonding CAN interfaces is architecturally invalid as CAN lacks<br /> MAC addresses, ARP capabilities, and standard Ethernet<br /> link-layer mechanisms. While generic loopback devices are<br /> blocked globally in net/core/dev.c, virtual CAN devices<br /> bypass this check because they do not carry the IFF_LOOPBACK<br /> flag, despite acting as local software-loopbacks.<br /> <br /> Fix this by explicitly blocking network devices of type<br /> ARPHRD_CAN from being enslaved at the very beginning of<br /> bond_enslave(). This prevents illegal state mutations,<br /> eliminates the resulting KASAN crashes, and avoids potential<br /> memory leaks from incomplete socket cleanups.<br /> <br /> As the CAN support has been added a long time after bonding<br /> the Fixes-tag points to the introduction of ARPHRD_CAN that<br /> would have needed a specific handling in bonding_main.c.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: Use spin_lock_bh for hn_lock<br /> <br /> nvmet_tcp_state_change(), a socket callback that runs in BH context,<br /> can reach handshake_req_cancel() via nvmet_tcp_schedule_release_queue()<br /> and tls_handshake_cancel(). handshake_req_cancel() acquires<br /> hn-&gt;hn_lock with plain spin_lock(). If a process-context thread on<br /> the same CPU holds hn-&gt;hn_lock when a softirq invokes the cancel path,<br /> the lock attempt deadlocks. This is the only caller that invokes<br /> tls_handshake_cancel() from BH context; every other consumer calls it<br /> from process context.<br /> <br /> Deferring the cancel to process context in the NVMe target is not<br /> straightforward: nvmet_tcp_schedule_release_queue() must call<br /> tls_handshake_cancel() atomically with its state transition to<br /> DISCONNECTING. If the cancel were deferred, the handshake completion<br /> callback could fire in the window before the cancel runs, observe the<br /> unexpected state, and return without dropping its kref on the queue.<br /> Reworking that interlock is considerably more invasive than hardening<br /> the handshake lock. Convert all hn-&gt;hn_lock acquisitions from<br /> spin_lock/spin_unlock to spin_lock_bh/spin_unlock_bh so the lock is<br /> never taken with softirqs enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mirred: Fix blockcast recursion bypass leading to stack overflow<br /> <br /> tcf_mirred_act() checks sched_mirred_nest against MIRRED_NEST_LIMIT (4)<br /> to prevent deep recursion. However, when the action uses blockcast<br /> (tcfm_blockid != 0), the function returns at the tcf_blockcast() call<br /> BEFORE reaching the counter increment. As a result, the recursion<br /> counter never advances and the limit check is entirely bypassed.<br /> <br /> When two devices share a TC egress block with a mirred blockcast rule,<br /> a packet egressing on device A is mirrored to device B via blockcast;<br /> device B&amp;#39;s egress TC re-enters tcf_mirred_act() via blockcast and<br /> mirrors back to A, creating an unbounded recursion loop:<br /> <br /> tcf_mirred_act -&gt; tcf_blockcast -&gt; tcf_mirred_to_dev -&gt; dev_queue_xmit<br /> -&gt; sch_handle_egress -&gt; tcf_classify -&gt; tcf_mirred_act -&gt; (repeat)<br /> <br /> This recursion continues until the kernel stack overflows.<br /> <br /> The bug is reachable from an unprivileged user via<br /> unshare(CLONE_NEWUSER | CLONE_NEWNET): user namespaces grant<br /> CAP_NET_ADMIN in the new network namespace, which is sufficient to<br /> create dummy devices, attach clsact qdiscs with shared blocks, and<br /> install mirred blockcast filters.<br /> <br /> BUG: TASK stack guard page was hit at ffffc90000b7fff8<br /> Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 2 UID: 1000 PID: 169 Comm: poc Not tainted 7.0.0-rc7-next-20260410<br /> RIP: 0010:xas_find+0x17/0x480<br /> Call Trace:<br /> xa_find+0x17b/0x1d0<br /> tcf_mirred_act+0x640/0x1060<br /> tcf_action_exec+0x400/0x530<br /> basic_classify+0x128/0x1d0<br /> tcf_classify+0xd83/0x1150<br /> tc_run+0x328/0x620<br /> __dev_queue_xmit+0x797/0x3100<br /> tcf_mirred_to_dev+0x7b1/0xf70<br /> tcf_mirred_act+0x68a/0x1060<br /> [repeating ~30+ times until stack overflow]<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Fix this by incrementing sched_mirred_nest before calling<br /> tcf_blockcast() and decrementing it on return, mirroring the<br /> non-blockcast path. This ensures subsequent recursive entries see the<br /> updated counter and are correctly limited by MIRRED_NEST_LIMIT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Fix ethx:ingress -&gt; ethy:egress -&gt; ethx:ingress mirred loop<br /> <br /> When mirred redirects to ingress (from either ingress or egress) the loop<br /> state from sched_mirred_dev array dev is lost because of 1) the packet<br /> deferral into the backlog and 2) the fact the sched_mirred_dev array is<br /> cleared. In such cases, if there was a loop we won&amp;#39;t discover it.<br /> <br /> Here&amp;#39;s a simple test to reproduce:<br /> ip a add dev port0 10.10.10.11/24<br /> <br /> tc qdisc add dev port0 clsact<br /> tc filter add dev port0 egress protocol ip \<br /> prio 10 matchall action mirred ingress redirect dev port1<br /> <br /> tc qdisc add dev port1 clsact<br /> tc filter add dev port1 ingress protocol ip \<br /> prio 10 matchall action mirred egress redirect dev port0<br /> <br /> ping -c 1 -W0.01 10.10.10.10

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: fix packet loop on netem when duplicate is on<br /> <br /> When netem duplicates a packet it re-enqueues the copy at the root qdisc.<br /> If another netem sits in the tree the copy can be duplicated<br /> again, recursing until the stack or memory is exhausted.<br /> <br /> The original duplication guard temporarily zeroed q-&gt;duplicate around<br /> the re-enqueue, but that does not cover all cases because it is<br /> per-qdisc state shared across all concurrent enqueue paths<br /> and is not safe without additional locking.<br /> <br /> Use the skb tc_depth field introduced in an earlier patch:<br /> - increment it on the duplicate before re-enqueue<br /> - skip duplication for any skb whose tc_depth is already non-zero.<br /> <br /> This marks the packet itself rather than mutating qdisc state,<br /> therefore it is safe regardless of tree topology or concurrency.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()<br /> <br /> ipv6_rpl_srh_decompress() computes:<br /> <br /> outhdr-&gt;hdrlen = (((n + 1) * sizeof(struct in6_addr)) &gt;&gt; 3);<br /> <br /> hdrlen is __u8. For n &gt;= 127 the result exceeds 255 and silently<br /> truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):<br /> <br /> (128 * 16) &gt;&gt; 3 = 256, truncated to 0 as __u8<br /> <br /> The caller in ipv6_rpl_srh_rcv() then places the compressed header<br /> at buf + ((ohdr-&gt;hdrlen + 1) &gt; 3 = 254, which fits in __u8. The compressed<br /> header then lands at buf + ((254 + 1)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: eeprom: add more safeties to EEPROM Netlink fallback<br /> <br /> The Netlink fallback path for reading module EEPROM<br /> (fallback_set_params()) validates that offset total_len)<br /> return -EINVAL;<br /> <br /> This could lead to surprises in both drivers and device FW.<br /> Add the missing offset + length validation to fallback_set_params(),<br /> mirroring the ioctl.<br /> <br /> Similarly - ethtool core in general, and ethtool_get_any_eeprom()<br /> in particular tries to zero-init all buffers passed to the drivers<br /> to avoid any extra work of zeroing things out. eeprom_fallback()<br /> uses a plain kmalloc(), change it to zalloc.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: tsinfo: don&amp;#39;t pass ERR_PTR to genlmsg_cancel on prepare failure<br /> <br /> The goto err label leads to:<br /> <br /> genlmsg_cancel(skb, ehdr);<br /> return ret;<br /> <br /> If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg.<br /> There&amp;#39;s nothing to cancel, and passing an error pointer to<br /> genlmsg_cancel() would cause a crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: coalesce: cap profile updates at NET_DIM_PARAMS_NUM_PROFILES<br /> <br /> ethnl_update_profile() walks the ETHTOOL_A_PROFILE_IRQ_MODERATION<br /> nest list with an index &amp;#39;i&amp;#39; and writes new_profile[i++] without<br /> bounding i. The destination is kmemdup()&amp;#39;d at NET_DIM_PARAMS_NUM_PROFILES<br /> entries (5), but the Netlink nest count is entirely user-controlled.<br /> Netlink policies do not have support for constraining the number<br /> of nested entries (or number of multi-attr entries).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: hand off the pinned file reference to accept_doit<br /> <br /> handshake_req_next() removes the request from the per-net<br /> pending list and drops hn_lock before handshake_nl_accept_doit()<br /> reads req-&gt;hr_sk-&gt;sk_socket and dereferences sock-&gt;file (once in<br /> FD_PREPARE() and again in get_file()). In that window a<br /> consumer running tls_handshake_cancel() followed by sockfd_put()<br /> (svc_sock_free) or __fput_sync() (xs_reset_transport) releases<br /> sock-&gt;file. sock_release() then runs sock_orphan(), zeroing<br /> sk_socket, and frees the struct socket. The accept-side code<br /> either reads NULL through sk_socket or chases freed memory.<br /> <br /> The submit-side sock_hold() does not prevent this. sk_refcnt<br /> protects struct sock, but struct socket and sock-&gt;file are<br /> independently refcounted via the file descriptor the consumer<br /> owns. Pinning sk leaves sock and sock-&gt;file unprotected.<br /> <br /> Retarget the accept-side dereferences at req-&gt;hr_file, which was<br /> pinned at submit time, instead of req-&gt;hr_sk-&gt;sk_socket-&gt;file.<br /> Pinning on its own is not sufficient: a consumer that cancels<br /> between handshake_req_next() returning and accept_doit reaching<br /> FD_PREPARE() takes the !remove_pending() branch in<br /> handshake_req_cancel() and drops hr_file before the accept side<br /> takes its own reference. Hand off an additional file reference<br /> inside handshake_req_next(), under hn_lock, so the accept side<br /> operates on a reference that no concurrent handshake_req_cancel()<br /> can revoke. FD_PREPARE() consumes that handed-off reference,<br /> either by transferring it to the new fd in fd_publish() or by<br /> dropping it in the cleanup destructor on error; the explicit<br /> get_file() that previously balanced FD_PREPARE() is therefore<br /> redundant and goes away.<br /> <br /> Update handshake_req_cancel_test2 and _test3 to simulate the<br /> FD_PREPARE() consumption with an fput() so the kunit file-count<br /> assertions stay balanced.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: bind uarg before filling zerocopy skb<br /> <br /> virtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg<br /> before entering the send loop, but virtio_transport_alloc_skb() still<br /> fills the skb before it inherits that uarg. When fixed-buffer vectored<br /> zerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach<br /> managed frags and return -EMSGSIZE. The rollback path call kfree_skb()<br /> to free an skb that carries SKBFL_MANAGED_FRAG_REFS but no uarg, so<br /> skb_release_data() falls through to ordinary frag unref.<br /> <br /> Pass the uarg into virtio_transport_alloc_skb() and bind it immediately<br /> before virtio_transport_fill_skb(). This keeps control or no-payload skbs<br /> untouched while ensuring success and rollback share one lifetime rule.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix race between sctp_wait_for_connect and peeloff<br /> <br /> sctp_wait_for_connect() drops and re-acquires the socket lock while<br /> waiting for the association to reach ESTABLISHED state. During this<br /> window, another thread can peeloff the association to a new socket via<br /> getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc-&gt;base.sk. After<br /> re-acquiring the old socket lock, sctp_wait_for_connect() returns<br /> success without noticing the migration — the caller then accesses<br /> the association under the wrong lock in sctp_datamsg_from_user().<br /> <br /> Add the same sk != asoc-&gt;base.sk check that sctp_wait_for_sndbuf()<br /> already has, returning an error if the association was migrated while<br /> we slept.