Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc, afs: Fix missing error pointer check after rxrpc_kernel_lookup_peer()<br /> <br /> rxrpc_kernel_lookup_peer() can also return error pointers in addition to<br /> NULL, so just checking for NULL is not sufficient.<br /> <br /> Fix this by:<br /> <br /> (1) Changing rxrpc_kernel_lookup_peer() to return -ENOMEM rather than NULL<br /> on allocation failure.<br /> <br /> (2) Making the callers in afs use IS_ERR() and PTR_ERR() to pass on the<br /> error code returned.

*** 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 legacy 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 /> Such issue can be observed with the<br /> test_xdp_native_adjst_tail_shrnk_data selftest when using a payload of<br /> 3600 and shrinking by 256 bytes (an upcoming selftest patch): the last<br /> fragment gets released by the XDP code but doesn&amp;#39;t get tracked by the<br /> driver. This results in a negative pp_ref_count during page release and<br /> the following splat:<br /> <br /> WARNING: include/net/page_pool/helpers.h:297 at mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core], CPU#12: ip/3137<br /> Modules linked in: [...]<br /> CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core]<br /> [...]<br /> Call Trace:<br /> <br /> mlx5e_dealloc_rx_wqe+0xcb/0x1a0 [mlx5_core]<br /> mlx5e_free_rx_descs+0x7f/0x110 [mlx5_core]<br /> mlx5e_close_rq+0x50/0x60 [mlx5_core]<br /> mlx5e_close_queues+0x36/0x2c0 [mlx5_core]<br /> mlx5e_close_channel+0x1c/0x50 [mlx5_core]<br /> mlx5e_close_channels+0x45/0x80 [mlx5_core]<br /> mlx5e_safe_switch_params+0x1a5/0x230 [mlx5_core]<br /> mlx5e_change_mtu+0xf3/0x2f0 [mlx5_core]<br /> netif_set_mtu_ext+0xf1/0x230<br /> do_setlink.isra.0+0x219/0x1180<br /> rtnl_newlink+0x79f/0xb60<br /> rtnetlink_rcv_msg+0x213/0x3a0<br /> netlink_rcv_skb+0x48/0xf0<br /> netlink_unicast+0x24a/0x350<br /> netlink_sendmsg+0x1ee/0x410<br /> __sock_sendmsg+0x38/0x60<br /> ____sys_sendmsg+0x232/0x280<br /> ___sys_sendmsg+0x78/0xb0<br /> __sys_sendmsg+0x5f/0xb0<br /> [...]<br /> do_syscall_64+0x57/0xc50<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: 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 /> net/mlx5: Fix crash when moving to switchdev mode<br /> <br /> When moving to switchdev mode when the device doesn&amp;#39;t support IPsec,<br /> we try to clean up the IPsec resources anyway which causes the crash<br /> below, fix that by correctly checking for IPsec support before trying<br /> to clean up its resources.<br /> <br /> [27642.515799] WARNING: arch/x86/mm/fault.c:1276 at<br /> do_user_addr_fault+0x18a/0x680, CPU#4: devlink/6490<br /> [27642.517159] Modules linked in: xt_conntrack xt_MASQUERADE<br /> ip6table_nat ip6table_filter ip6_tables iptable_nat nf_nat xt_addrtype<br /> rpcsec_gss_krb5 auth_rpcgss oid_registry overlay mlx5_fwctl nfnetlink<br /> zram zsmalloc mlx5_ib fuse rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi<br /> scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_core<br /> ib_core<br /> [27642.521358] CPU: 4 UID: 0 PID: 6490 Comm: devlink Not tainted<br /> 6.19.0-rc5_for_upstream_min_debug_2026_01_14_16_47 #1 NONE<br /> [27642.522923] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [27642.524528] RIP: 0010:do_user_addr_fault+0x18a/0x680<br /> [27642.525362] Code: ff 0f 84 75 03 00 00 48 89 ee 4c 89 e7 e8 5e b9 22<br /> 00 49 89 c0 48 85 c0 0f 84 a8 02 00 00 f7 c3 60 80 00 00 74 22 31 c9 eb<br /> ae 0b 48 83 c4 10 48 89 ea 48 89 de 4c 89 f7 5b 5d 41 5c 41 5d<br /> 41<br /> [27642.528166] RSP: 0018:ffff88810770f6b8 EFLAGS: 00010046<br /> [27642.529038] RAX: 0000000000000000 RBX: 0000000000000002 RCX:<br /> ffff88810b980f00<br /> [27642.530158] RDX: 00000000000000a0 RSI: 0000000000000002 RDI:<br /> ffff88810770f728<br /> [27642.531270] RBP: 00000000000000a0 R08: 0000000000000000 R09:<br /> 0000000000000000<br /> [27642.532383] R10: 0000000000000000 R11: 0000000000000000 R12:<br /> ffff888103f3c4c0<br /> [27642.533499] R13: 0000000000000000 R14: ffff88810770f728 R15:<br /> 0000000000000000<br /> [27642.534614] FS: 00007f197c741740(0000) GS:ffff88856a94c000(0000)<br /> knlGS:0000000000000000<br /> [27642.535915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [27642.536858] CR2: 00000000000000a0 CR3: 000000011334c003 CR4:<br /> 0000000000172eb0<br /> [27642.537982] Call Trace:<br /> [27642.538466] <br /> [27642.538907] exc_page_fault+0x76/0x140<br /> [27642.539583] asm_exc_page_fault+0x22/0x30<br /> [27642.540282] RIP: 0010:_raw_spin_lock_irqsave+0x10/0x30<br /> [27642.541134] Code: 07 85 c0 75 11 ba ff 00 00 00 f0 0f b1 17 75 06 b8<br /> 01 00 00 00 c3 31 c0 c3 90 0f 1f 44 00 00 53 9c 5b fa 31 c0 ba 01 00 00<br /> 00 0f b1 17 75 05 48 89 d8 5b c3 89 c6 e8 7e 02 00 00 48 89 d8<br /> 5b<br /> [27642.543936] RSP: 0018:ffff88810770f7d8 EFLAGS: 00010046<br /> [27642.544803] RAX: 0000000000000000 RBX: 0000000000000202 RCX:<br /> ffff888113ad96d8<br /> [27642.545916] RDX: 0000000000000001 RSI: ffff88810770f818 RDI:<br /> 00000000000000a0<br /> [27642.547027] RBP: 0000000000000098 R08: 0000000000000400 R09:<br /> ffff88810b980f00<br /> [27642.548140] R10: 0000000000000001 R11: ffff888101845a80 R12:<br /> 00000000000000a8<br /> [27642.549263] R13: ffffffffa02a9060 R14: 00000000000000a0 R15:<br /> ffff8881130d8a40<br /> [27642.550379] complete_all+0x20/0x90<br /> [27642.551010] mlx5e_ipsec_disable_events+0xb6/0xf0 [mlx5_core]<br /> [27642.552022] mlx5e_nic_disable+0x12d/0x220 [mlx5_core]<br /> [27642.552929] mlx5e_detach_netdev+0x66/0xf0 [mlx5_core]<br /> [27642.553822] mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core]<br /> [27642.554821] mlx5e_vport_rep_load+0x419/0x590 [mlx5_core]<br /> [27642.555757] ? xa_load+0x53/0x90<br /> [27642.556361] __esw_offloads_load_rep+0x54/0x70 [mlx5_core]<br /> [27642.557328] mlx5_esw_offloads_rep_load+0x45/0xd0 [mlx5_core]<br /> [27642.558320] esw_offloads_enable+0xb4b/0xc90 [mlx5_core]<br /> [27642.559247] mlx5_eswitch_enable_locked+0x34e/0x4f0 [mlx5_core]<br /> [27642.560257] ? mlx5_rescan_drivers_locked+0x222/0x2d0 [mlx5_core]<br /> [27642.561284] mlx5_devlink_eswitch_mode_set+0x5ac/0x9c0 [mlx5_core]<br /> [27642.562334] ? devlink_rate_set_ops_supported+0x21/0x3a0<br /> [27642.563220] devlink_nl_eswitch_set_doit+0x67/0xe0<br /> [27642.564026] genl_family_rcv_msg_doit+0xe0/0x130<br /> [27642.564816] genl_rcv_msg+0x183/0x290<br /> [27642.565466] ? __devlink_nl_pre_doit.isra.0+0x160/0x160<br /> [27642.566329] ? d<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix deadlock between devlink lock and esw-&gt;wq<br /> <br /> esw-&gt;work_queue executes esw_functions_changed_event_handler -&gt;<br /> esw_vfs_changed_event_handler and acquires the devlink lock.<br /> <br /> .eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -&gt;<br /> mlx5_devlink_eswitch_mode_set -&gt; mlx5_eswitch_disable_locked -&gt;<br /> mlx5_eswitch_event_handler_unregister -&gt; flush_workqueue deadlocks<br /> when esw_vfs_changed_event_handler executes.<br /> <br /> Fix that by no longer flushing the work to avoid the deadlock, and using<br /> a generation counter to keep track of work relevance. This avoids an old<br /> handler manipulating an esw that has undergone one or more mode changes:<br /> - the counter is incremented in mlx5_eswitch_event_handler_unregister.<br /> - the counter is read and passed to the ephemeral mlx5_host_work struct.<br /> - the work handler takes the devlink lock and bails out if the current<br /> generation is different than the one it was scheduled to operate on.<br /> - mlx5_eswitch_cleanup does the final draining before destroying the wq.<br /> <br /> No longer flushing the workqueue has the side effect of maybe no longer<br /> cancelling pending vport_change_handler work items, but that&amp;#39;s ok since<br /> those are disabled elsewhere:<br /> - mlx5_eswitch_disable_locked disables the vport eq notifier.<br /> - mlx5_esw_vport_disable disarms the HW EQ notification and marks<br /> vport-&gt;enabled under state_lock to false to prevent pending vport<br /> handler from doing anything.<br /> - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events<br /> are disabled/finished.

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