Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()<br /> <br /> skb_tunnel_check_pmtu() can change skb-&gt;head.<br /> <br /> Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF.<br /> <br /> Use instead ip_hdr(skb) as done in drivers/net/bareudp.c<br /> and drivers/net/geneve.c.<br /> <br /> Found by Sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]()<br /> <br /> Sashiko found that iptunnel_pmtud_build_icmp() and<br /> iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr()<br /> before an skb_cow() call which can reallocate skb-&gt;head.<br /> <br /> Fix this possible UAF by initializing the local variables<br /> after the skb_cow() call.<br /> <br /> Remove skb_reset_network_header() calls which were not needed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()<br /> <br /> The skb_clone() function can return NULL if memory allocation fails.<br /> send_mcast_pkt() calls skb_clone() without checking the return value, which<br /> can lead to a NULL pointer dereference in send_pkt() when it dereferences<br /> skb-&gt;data.<br /> Add a NULL check after skb_clone() and skip the peer if the clone fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: Fix sleep in atomic context in sysfs path<br /> <br /> Since the start of the git history, brport_store() always acquired the<br /> bridge lock. Back then this decision made sense: The bridge lock<br /> protects the STP state of the bridge and its ports and at that time the<br /> function was only used by two STP related attributes (cost and<br /> priority).<br /> <br /> Nowadays, brport_store() processes a lot more attributes and most of<br /> them do not need the bridge lock:<br /> <br /> * Bridge flags: Only require RTNL. Read locklessly by the data path.<br /> Annotations can be added in net-next.<br /> <br /> * FDB port flushing: Only requires the FDB lock.<br /> <br /> * Multicast attributes: Only require the multicast lock.<br /> <br /> * Group forward mask: Only requires RTNL. Read locklessly by the data<br /> path. Annotations can be added in net-next.<br /> <br /> * Backup port: Only requires RTNL. Read locklessly by the data path.<br /> <br /> This is a problem as the bridge calls dev_set_promiscuity() when certain<br /> bridge port flags change and this function can sleep since the commit<br /> cited below, resulting in a splat such as [1].<br /> <br /> Fix this by reducing the scope of the bridge lock and only take it when<br /> processing the two STP related attributes that require it. Remove the<br /> now stale comment from br_switchdev_set_port_flag(). The<br /> SWITCHDEV_F_DEFER flag can be removed in net-next.<br /> <br /> [1]<br /> BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 372, name: bash<br /> preempt_count: 201, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 5 locks held by bash/372:<br /> #0: ffff88810c51c3f0 (sb_writers#7){.+.+}-{0:0}, at: ksys_write (fs/read_write.c:740)<br /> #1: ffff888115ce9480 (&amp;of-&gt;mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter (fs/kernfs/file.c:343)<br /> #2: ffff88810b9fd330 (kn-&gt;active#37){.+.+}-{0:0}, at: kernfs_fop_write_iter (fs/kernfs/file.c:80 fs/kernfs/file.c:344)<br /> #3: ffffffffa59473a0 (rtnl_mutex){+.+.}-{4:4}, at: brport_store (net/bridge/br_sysfs_if.c:326)<br /> #4: ffff8881099d2d58 (&amp;br-&gt;lock){+...}-{3:3}, at: brport_store (./include/linux/spinlock.h:348 net/bridge/br_sysfs_if.c:345)<br /> Preemption disabled at:<br /> 0x0<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)<br /> __might_resched.cold (kernel/sched/core.c:9163)<br /> netif_rx_mode_run (net/core/dev_addr_lists.c:1262)<br /> netif_rx_mode_sync (net/core/dev_addr_lists.c:1428)<br /> dev_set_promiscuity (net/core/dev_api.c:289)<br /> br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172)<br /> br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747)<br /> store_learning (net/bridge/br_sysfs_if.c:79 net/bridge/br_sysfs_if.c:235)<br /> brport_store (net/bridge/br_sysfs_if.c:346)<br /> kernfs_fop_write_iter (fs/kernfs/file.c:352)<br /> new_sync_write (fs/read_write.c:595)<br /> vfs_write (fs/read_write.c:688)<br /> ksys_write (fs/read_write.c:740)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<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 /> bridge: Fix sleep in atomic context in netlink path<br /> <br /> Since the introduction of the netlink configuration path for bridge<br /> ports in commit 25c71c75ac87 ("bridge: bridge port parameters over<br /> netlink"), br_setport() was always called with the bridge lock held<br /> around it. Back then this decision made sense: The bridge lock protects<br /> the STP state of the bridge and its ports and at that time the function<br /> only processed three STP related netlink attributes (cost, priority and<br /> state).<br /> <br /> Nowadays, br_setport() processes a lot more attributes and most of them<br /> do not need the bridge lock:<br /> <br /> * Bridge flags: Only require RTNL. Read locklessly by the data path.<br /> Annotations can be added in net-next.<br /> <br /> * FDB port flushing: Only requires the FDB lock.<br /> <br /> * Multicast attributes: Only require the multicast lock.<br /> <br /> * Group forward mask: Only requires RTNL. Read locklessly by the data<br /> path. Annotations can be added in net-next.<br /> <br /> * Backup port and NHID: Only require RTNL. Read locklessly by the data<br /> path.<br /> <br /> This is a problem as the bridge calls dev_set_promiscuity() when certain<br /> bridge port flags change and this function can sleep since the commit<br /> cited below, resulting in a splat such as [1].<br /> <br /> Fix this by reducing the scope of the bridge lock and only take it when<br /> processing the three STP related attributes that require it. This is<br /> consistent with the multicast attributes where each attribute acquires<br /> the multicast lock instead of having one critical section for all<br /> relevant attributes.<br /> <br /> [1]<br /> BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge<br /> preempt_count: 201, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 2 locks held by bridge/356:<br /> #0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002)<br /> #1: ffff888115072d58 (&amp;br-&gt;lock){+...}-{3:3}, at: br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117)<br /> Preemption disabled at:<br /> 0x0<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)<br /> __might_resched.cold (kernel/sched/core.c:9163)<br /> netif_rx_mode_run (net/core/dev_addr_lists.c:1262)<br /> netif_rx_mode_sync (net/core/dev_addr_lists.c:1428)<br /> dev_set_promiscuity (net/core/dev_api.c:289)<br /> br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172)<br /> br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747)<br /> br_setport (net/bridge/br_netlink.c:1000)<br /> br_setlink (net/bridge/br_netlink.c:1118)<br /> rtnl_bridge_setlink (net/core/rtnetlink.c:5572)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:7005)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> netlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1894)<br /> __sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4))<br /> ____sys_sendmsg (net/socket.c:2698)<br /> ___sys_sendmsg (net/socket.c:2752)<br /> __sys_sendmsg (net/socket.c:2784)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<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 /> 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: 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 /> 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)