Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ<br /> <br /> XDP multi-buf programs can modify the layout of the XDP buffer when the<br /> program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The<br /> referenced commit in the fixes tag corrected the assumption in the mlx5<br /> driver that the XDP buffer layout doesn&amp;#39;t change during a program<br /> execution. However, this fix introduced another issue: the dropped<br /> fragments still need to be counted on the driver side to avoid page<br /> fragment reference counting issues.<br /> <br /> The issue was discovered by the drivers/net/xdp.py selftest,<br /> more specifically the test_xdp_native_tx_mb:<br /> - The mlx5 driver allocates a page_pool page and initializes it with<br /> a frag counter of 64 (pp_ref_count=64) and the internal frag counter<br /> to 0.<br /> - The test sends one packet with no payload.<br /> - On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP<br /> buffer with the packet data starting in the first fragment which is the<br /> page mentioned above.<br /> - The XDP program runs and calls bpf_xdp_pull_data() which moves the<br /> header into the linear part of the XDP buffer. As the packet doesn&amp;#39;t<br /> contain more data, the program drops the tail fragment since it no<br /> longer contains any payload (pp_ref_count=63).<br /> - mlx5 device skips counting this fragment. Internal frag counter<br /> remains 0.<br /> - mlx5 releases all 64 fragments of the page but page pp_ref_count is<br /> 63 =&gt; negative reference counting error.<br /> <br /> Resulting splat during the test:<br /> <br /> WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core]<br /> Modules linked in: [...]<br /> CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core]<br /> [...]<br /> Call Trace:<br /> <br /> mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core]<br /> mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core]<br /> mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core]<br /> mlx5e_close_rq+0x78/0xa0 [mlx5_core]<br /> mlx5e_close_queues+0x46/0x2a0 [mlx5_core]<br /> mlx5e_close_channel+0x24/0x90 [mlx5_core]<br /> mlx5e_close_channels+0x5d/0xf0 [mlx5_core]<br /> mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core]<br /> mlx5e_change_mtu+0x11d/0x490 [mlx5_core]<br /> mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core]<br /> netif_set_mtu_ext+0xfc/0x240<br /> do_setlink.isra.0+0x226/0x1100<br /> rtnl_newlink+0x7a9/0xba0<br /> rtnetlink_rcv_msg+0x220/0x3c0<br /> netlink_rcv_skb+0x4b/0xf0<br /> netlink_unicast+0x255/0x380<br /> netlink_sendmsg+0x1f3/0x420<br /> __sock_sendmsg+0x38/0x60<br /> ____sys_sendmsg+0x1e8/0x240<br /> ___sys_sendmsg+0x7c/0xb0<br /> [...]<br /> __sys_sendmsg+0x5f/0xb0<br /> do_syscall_64+0x55/0xc70<br /> <br /> The problem applies for XDP_PASS as well which is handled in a different<br /> code path in the driver.<br /> <br /> This patch fixes the issue by doing page frag counting on all the<br /> original XDP buffer fragments for all relevant XDP actions (XDP_TX ,<br /> XDP_REDIRECT and XDP_PASS). This is basically reverting to the original<br /> counting before the commit in the fixes tag.<br /> <br /> As frag_page is still pointing to the original tail, the nr_frags<br /> parameter to xdp_update_skb_frags_info() needs to be calculated<br /> in a different way to reflect the new nr_frags.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery<br /> <br /> In case of a TX error CQE, a recovery flow is triggered,<br /> mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,<br /> desyncing the DMA FIFO producer and consumer.<br /> <br /> After recovery, the producer pushes new DMA entries at the old<br /> dma_fifo_pc, while the consumer reads from position 0.<br /> This causes us to unmap stale DMA addresses from before the recovery.<br /> <br /> The DMA FIFO is a purely software construct with no HW counterpart.<br /> At the point of reset, all WQEs have been flushed so dma_fifo_cc is<br /> already equal to dma_fifo_pc. There is no need to reset either counter,<br /> similar to how skb_fifo pc/cc are untouched.<br /> <br /> Remove the &amp;#39;dma_fifo_cc = 0&amp;#39; reset.<br /> <br /> This fixes the following WARNING:<br /> WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90<br /> Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables]<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:iommu_dma_unmap_page+0x79/0x90<br /> Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00<br /> Call Trace:<br /> <br /> ? __warn+0x7d/0x110<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> ? report_bug+0x16d/0x180<br /> ? handle_bug+0x4f/0x90<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> ? iommu_dma_unmap_page+0x2e/0x90<br /> dma_unmap_page_attrs+0x10d/0x1b0<br /> mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core]<br /> mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core]<br /> mlx5e_napi_poll+0x8b/0xac0 [mlx5_core]<br /> __napi_poll+0x24/0x190<br /> net_rx_action+0x32a/0x3b0<br /> ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core]<br /> ? notifier_call_chain+0x35/0xa0<br /> handle_softirqs+0xc9/0x270<br /> irq_exit_rcu+0x71/0xd0<br /> common_interrupt+0x7f/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xprtrdma: Decrement re_receiving on the early exit paths<br /> <br /> In the event that rpcrdma_post_recvs() fails to create a work request<br /> (due to memory allocation failure, say) or otherwise exits early, we<br /> should decrement ep-&gt;re_receiving before returning. Otherwise we will<br /> hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and<br /> the completion will never be triggered.<br /> <br /> On a system with high memory pressure, this can appear as the following<br /> hung task:<br /> <br /> INFO: task kworker/u385:17:8393 blocked for more than 122 seconds.<br /> Tainted: G S E 6.19.0 #3<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000<br /> Workqueue: xprtiod xprt_autoclose [sunrpc]<br /> Call Trace:<br /> <br /> __schedule+0x48b/0x18b0<br /> ? ib_post_send_mad+0x247/0xae0 [ib_core]<br /> schedule+0x27/0xf0<br /> schedule_timeout+0x104/0x110<br /> __wait_for_common+0x98/0x180<br /> ? __pfx_schedule_timeout+0x10/0x10<br /> wait_for_completion+0x24/0x40<br /> rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma]<br /> xprt_rdma_close+0x12/0x40 [rpcrdma]<br /> xprt_autoclose+0x5f/0x120 [sunrpc]<br /> process_one_work+0x191/0x3e0<br /> worker_thread+0x2e3/0x420<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x10d/0x230<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x273/0x2b0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()<br /> <br /> pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the<br /> to_offset argument on every iteration, including the last one where<br /> i == m-&gt;field_count - 1. This reads one element past the end of the<br /> stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS]<br /> with NFT_PIPAPO_MAX_FIELDS == 16).<br /> <br /> Although pipapo_unmap() returns early when is_last is true without<br /> using the to_offset value, the argument is evaluated at the call site<br /> before the function body executes, making this a genuine out-of-bounds<br /> stack read confirmed by KASAN:<br /> <br /> BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables]<br /> Read of size 4 at addr ffff8000810e71a4<br /> <br /> This frame has 1 object:<br /> [32, 160) &amp;#39;rulemap&amp;#39;<br /> <br /> The buggy address is at offset 164 -- exactly 4 bytes past the end<br /> of the rulemap array.<br /> <br /> Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid<br /> the out-of-bounds read.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: route: hold key-&gt;lock in mctp_flow_prepare_output()<br /> <br /> mctp_flow_prepare_output() checks key-&gt;dev and may call<br /> mctp_dev_set_key(), but it does not hold key-&gt;lock while doing so.<br /> <br /> mctp_dev_set_key() and mctp_dev_release_key() are annotated with<br /> __must_hold(&amp;key-&gt;lock), so key-&gt;dev access is intended to be<br /> serialized by key-&gt;lock. The mctp_sendmsg() transmit path reaches<br /> mctp_flow_prepare_output() via mctp_local_output() -&gt; mctp_dst_output()<br /> without holding key-&gt;lock, so the check-and-set sequence is racy.<br /> <br /> Example interleaving:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> mctp_flow_prepare_output(key, devA)<br /> if (!key-&gt;dev) // sees NULL<br /> mctp_flow_prepare_output(<br /> key, devB)<br /> if (!key-&gt;dev) // still NULL<br /> mctp_dev_set_key(devB, key)<br /> mctp_dev_hold(devB)<br /> key-&gt;dev = devB<br /> mctp_dev_set_key(devA, key)<br /> mctp_dev_hold(devA)<br /> key-&gt;dev = devA // overwrites devB<br /> <br /> Now both devA and devB references were acquired, but only the final<br /> key-&gt;dev value is tracked for release. One reference can be lost,<br /> causing a resource leak as mctp_dev_release_key() would only decrease<br /> the reference on one dev.<br /> <br /> Fix by taking key-&gt;lock around the key-&gt;dev check and<br /> mctp_dev_set_key() call.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: i2c: fix skb memory leak in receive path<br /> <br /> When &amp;#39;midev-&gt;allow_rx&amp;#39; is false, the newly allocated skb isn&amp;#39;t consumed<br /> by netif_rx(), it needs to free the skb directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: caif: hold tty-&gt;link reference in ldisc_open and ser_release<br /> <br /> A reproducer triggers a KASAN slab-use-after-free in pty_write_room()<br /> when caif_serial&amp;#39;s TX path calls tty_write_room(). The faulting access<br /> is on tty-&gt;link-&gt;port.<br /> <br /> Hold an extra kref on tty-&gt;link for the lifetime of the caif_serial line<br /> discipline: get it in ldisc_open() and drop it in ser_release(), and<br /> also drop it on the ldisc_open() error path.<br /> <br /> With this change applied, the reproducer no longer triggers the UAF in<br /> my testing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: rockchip-sfc: Fix double-free in remove() callback<br /> <br /> The driver uses devm_spi_register_controller() for registration, which<br /> automatically unregisters the controller via devm cleanup when the<br /> device is removed. The manual call to spi_unregister_controller() in<br /> the remove() callback can lead to a double-free.<br /> <br /> And to make sure controller is unregistered before DMA buffer is<br /> unmapped, switch to use spi_register_controller() in probe().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix for duplicate device in netdev hooks<br /> <br /> When handling NETDEV_REGISTER notification, duplicate device<br /> registration must be avoided since the device may have been added by<br /> nft_netdev_hook_alloc() already when creating the hook.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix type confusion in bond_setup_by_slave()<br /> <br /> kernel BUG at net/core/skbuff.c:2306!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306<br /> RSP: 0018:ffffc90004aff760 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e<br /> RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900<br /> RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780<br /> R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900<br /> dev_hard_header include/linux/netdevice.h:3439 [inline]<br /> packet_snd net/packet/af_packet.c:3028 [inline]<br /> packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592<br /> ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646<br /> __sys_sendmsg+0x170/0x220 net/socket.c:2678<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe1a0e6c1a9<br /> <br /> When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,<br /> bond_setup_by_slave() directly copies the slave&amp;#39;s header_ops to the<br /> bond device:<br /> <br /> bond_dev-&gt;header_ops = slave_dev-&gt;header_ops;<br /> <br /> This causes a type confusion when dev_hard_header() is later called<br /> on the bond device. Functions like ipgre_header(), ip6gre_header(),all use<br /> netdev_priv(dev) to access their device-specific private data. When<br /> called with the bond device, netdev_priv() returns the bond&amp;#39;s private<br /> data (struct bonding) instead of the expected type (e.g. struct<br /> ip_tunnel), leading to garbage values being read and kernel crashes.<br /> <br /> Fix this by introducing bond_header_ops with wrapper functions that<br /> delegate to the active slave&amp;#39;s header_ops using the slave&amp;#39;s own<br /> device. This ensures netdev_priv() in the slave&amp;#39;s header functions<br /> always receives the correct device.<br /> <br /> The fix is placed in the bonding driver rather than individual device<br /> drivers, as the root cause is bond blindly inheriting header_ops from<br /> the slave without considering that these callbacks expect a specific<br /> netdev_priv() layout.<br /> <br /> The type confusion can be observed by adding a printk in<br /> ipgre_header() and running the following commands:<br /> <br /> ip link add dummy0 type dummy<br /> ip addr add 10.0.0.1/24 dev dummy0<br /> ip link set dummy0 up<br /> ip link add gre1 type gre local 10.0.0.1<br /> ip link add bond1 type bond mode active-backup<br /> ip link set gre1 master bond1<br /> ip link set gre1 up<br /> ip link set bond1 up<br /> ip addr add fe80::1/64 dev bond1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-core: flush delayed work before removing DAIs and widgets<br /> <br /> When a sound card is unbound while a PCM stream is open, a<br /> use-after-free can occur in snd_soc_dapm_stream_event(), called from<br /> the close_delayed_work workqueue handler.<br /> <br /> During unbind, snd_soc_unbind_card() flushes delayed work and then<br /> calls soc_cleanup_card_resources(). Inside cleanup,<br /> snd_card_disconnect_sync() releases all PCM file descriptors, and<br /> the resulting PCM close path can call snd_soc_dapm_stream_stop()<br /> which schedules new delayed work with a pmdown_time timer delay.<br /> Since this happens after the flush in snd_soc_unbind_card(), the<br /> new work is not caught. soc_remove_link_components() then frees<br /> DAPM widgets before this work fires, leading to the use-after-free.<br /> <br /> The existing flush in soc_free_pcm_runtime() also cannot help as it<br /> runs after soc_remove_link_components() has already freed the widgets.<br /> <br /> Add a flush in soc_cleanup_card_resources() after<br /> snd_card_disconnect_sync() (after which no new PCM closes can<br /> schedule further delayed work) and before soc_remove_link_dais()<br /> and soc_remove_link_components() (which tear down the structures the<br /> delayed work accesses).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic: spifc-a4: Fix DMA mapping error handling<br /> <br /> Fix three bugs in aml_sfc_dma_buffer_setup() error paths:<br /> 1. Unnecessary goto: When the first DMA mapping (sfc-&gt;daddr) fails,<br /> nothing needs cleanup. Use direct return instead of goto.<br /> 2. Double-unmap bug: When info DMA mapping failed, the code would<br /> unmap sfc-&gt;daddr inline, then fall through to out_map_data which<br /> would unmap it again, causing a double-unmap.<br /> 3. Wrong unmap size: The out_map_info label used datalen instead of<br /> infolen when unmapping sfc-&gt;iaddr, which could lead to incorrect<br /> DMA sync behavior.