Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm_user: fix info leak in build_mapping()<br /> <br /> struct xfrm_usersa_id has a one-byte padding hole after the proto<br /> field, which ends up never getting set to zero before copying out to<br /> userspace. Fix that up by zeroing out the whole structure before<br /> setting individual variables.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: fix refcount leak in xfrm_migrate_policy_find<br /> <br /> syzkaller reported a memory leak in xfrm_policy_alloc:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888114d79000 (size 1024):<br /> comm "syz.1.17", pid 931<br /> ...<br /> xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432<br /> <br /> The root cause is a double call to xfrm_pol_hold_rcu() in<br /> xfrm_migrate_policy_find(). The lookup function already returns<br /> a policy with held reference, making the second call redundant.<br /> <br /> Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount<br /> imbalance and prevent the memory leak.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Wait for RCU readers during policy netns exit<br /> <br /> xfrm_policy_fini() frees the policy_bydst hash tables after flushing the<br /> policy work items and deleting all policies, but it does not wait for<br /> concurrent RCU readers to leave their read-side critical sections first.<br /> <br /> The policy_bydst tables are published via rcu_assign_pointer() and are<br /> looked up through rcu_dereference_check(), so netns teardown must also<br /> wait for an RCU grace period before freeing the table memory.<br /> <br /> Fix this by adding synchronize_rcu() before freeing the policy hash tables.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: validate MTU against usable frame size on bind<br /> <br /> AF_XDP bind currently accepts zero-copy pool configurations without<br /> verifying that the device MTU fits into the usable frame space provided<br /> by the UMEM chunk.<br /> <br /> This becomes a problem since we started to respect tailroom which is<br /> subtracted from chunk_size (among with headroom). 2k chunk size might<br /> not provide enough space for standard 1500 MTU, so let us catch such<br /> settings at bind time. Furthermore, validate whether underlying HW will<br /> be able to satisfy configured MTU wrt XSK&amp;#39;s frame size multiplied by<br /> supported Rx buffer chain length (that is exposed via<br /> net_device::xdp_zc_max_segs).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: tighten UMEM headroom validation to account for tailroom and min frame<br /> <br /> The current headroom validation in xdp_umem_reg() could leave us with<br /> insufficient space dedicated to even receive minimum-sized ethernet<br /> frame. Furthermore if multi-buffer would come to play then<br /> skb_shared_info stored at the end of XSK frame would be corrupted.<br /> <br /> HW typically works with 128-aligned sizes so let us provide this value<br /> as bare minimum.<br /> <br /> Multi-buffer setting is known later in the configuration process so<br /> besides accounting for 128 bytes, let us also take care of tailroom space<br /> upfront.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: add missing negotiate_features op to Hyper-V ops table<br /> <br /> Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by<br /> negotiating supported features") added the .negotiate_features callback<br /> to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot<br /> to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL<br /> on Hyper-V VMs.<br /> <br /> During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(),<br /> which unconditionally dereferences hw-&gt;mac.ops.negotiate_features().<br /> On Hyper-V this results in a NULL pointer dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...]<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:0x0<br /> [...]<br /> Call Trace:<br /> ixgbevf_negotiate_api+0x66/0x160 [ixgbevf]<br /> ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf]<br /> ixgbevf_probe+0x20f/0x4a0 [ixgbevf]<br /> local_pci_probe+0x50/0xa0<br /> work_for_cpu_fn+0x1a/0x30<br /> [...]<br /> <br /> Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and<br /> wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP<br /> gracefully.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: Fix errors in IRQ cleanup<br /> <br /> IRQs are enabled through sdca_irq_populate() from component probe<br /> using devm_request_threaded_irq(), this however means the IRQs can<br /> persist if the sound card is torn down. Some of the IRQ handlers<br /> store references to the card and the kcontrols which can then<br /> fail. Some detail of the crash was explained in [1].<br /> <br /> Generally it is not advised to use devm outside of bus probe, so<br /> the code is updated to not use devm. The IRQ requests are not moved<br /> to bus probe time as it makes passing the snd_soc_component into<br /> the IRQs very awkward and would the require a second step once the<br /> component is available, so it is simpler to just register the IRQs<br /> at this point, even though that necessitates some manual cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: Drop large packets with UDP encap<br /> <br /> syzbot reported a WARN on my patch series [1]. The actual issue is an<br /> overflow of 16-bit UDP length field, and it exists in the upstream code.<br /> My series added a debug WARN with an overflow check that exposed the<br /> issue, that&amp;#39;s why syzbot tripped on my patches, rather than on upstream<br /> code.<br /> <br /> syzbot&amp;#39;s repro:<br /> <br /> r0 = socket$pppl2tp(0x18, 0x1, 0x1)<br /> r1 = socket$inet6_udp(0xa, 0x2, 0x0)<br /> connect$inet6(r1, &amp;(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c)<br /> connect$pppl2tp(r0, &amp;(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={&amp;#39;\x00&amp;#39;, &amp;#39;\xff\xff&amp;#39;, @empty}}}}, 0x32)<br /> writev(r0, &amp;(0x7f0000000080)=[{&amp;(0x7f0000000000)="ee", 0x34000}], 0x1)<br /> <br /> It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP<br /> encapsulation, and l2tp_xmit_core doesn&amp;#39;t check for overflows when it<br /> assigns the UDP length field. The value gets trimmed to 16 bites.<br /> <br /> Add an overflow check that drops oversized packets and avoids sending<br /> packets with trimmed UDP length to the wire.<br /> <br /> syzbot&amp;#39;s stack trace (with my patch applied):<br /> <br /> len &gt;= 65536u<br /> WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957<br /> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957<br /> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline]<br /> RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline]<br /> RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327<br /> Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f<br /> RSP: 0018:ffffc90003d67878 EFLAGS: 00010293<br /> RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000<br /> RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff<br /> RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004<br /> R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900<br /> R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000<br /> FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> sock_write_iter+0x503/0x550 net/socket.c:1195<br /> do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1<br /> vfs_writev+0x33c/0x990 fs/read_write.c:1059<br /> do_writev+0x154/0x2e0 fs/read_write.c:1105<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f636479c629<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014<br /> RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629<br /> RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003<br /> RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0<br /> <br /> <br /> [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+<br /> <br /> Fix the field masks to match the hardware layout documented in<br /> downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*).<br /> <br /> Notably this fixes a WARN I was seeing when I tried to send "stop"<br /> to the MPSS remoteproc while IPA was up.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: txgbe: leave space for null terminators on property_entry<br /> <br /> Lists of struct property_entry are supposed to be terminated with an<br /> empty property, this driver currently seems to be allocating exactly the<br /> amount of entry used.<br /> <br /> Change the struct definition to leave an extra element for all<br /> property_entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ioam6: fix OOB and missing lock<br /> <br /> When trace-&gt;type.bit6 is set:<br /> <br /> if (trace-&gt;type.bit6) {<br /> ...<br /> queue = skb_get_tx_queue(dev, skb);<br /> qdisc = rcu_dereference(queue-&gt;qdisc);<br /> <br /> This code can lead to an out-of-bounds access of the dev-&gt;_tx[] array<br /> when is_input is true. In such a case, the packet is on the RX path and<br /> skb-&gt;queue_mapping contains the RX queue index of the ingress device. If<br /> the ingress device has more RX queues than the egress device (dev) has<br /> TX queues, skb_get_queue_mapping(skb) will exceed dev-&gt;num_tx_queues.<br /> Add a check to avoid this situation since skb_get_tx_queue() does not<br /> clamp the index. This issue has also revealed that per queue visibility<br /> cannot be accurate and will be replaced later as a new feature.<br /> <br /> While at it, add missing lock around qdisc_qstats_qlen_backlog(). The<br /> function __ioam6_fill_trace_data() is called from both softirq and<br /> process contexts, hence the use of spin_lock_bh() here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: make hash table per queue<br /> <br /> Sharing a global hash table among all queues is tempting, but<br /> it can cause crash:<br /> <br /> BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]<br /> [..]<br /> nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]<br /> nfnetlink_rcv_msg+0x46a/0x930<br /> kmem_cache_alloc_node_noprof+0x11e/0x450<br /> <br /> struct nf_queue_entry is freed via kfree, but parallel cpu can still<br /> encounter such an nf_queue_entry when walking the list.<br /> <br /> Alternative fix is to free the nf_queue_entry via kfree_rcu() instead,<br /> but as we have to alloc/free for each skb this will cause more mem<br /> pressure.