Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject negative offsets for ALU ops<br /> <br /> When verifying BPF programs, the check_alu_op() function validates<br /> instructions with ALU operations. The &amp;#39;offset&amp;#39; field in these<br /> instructions is a signed 16-bit integer.<br /> <br /> The existing check &amp;#39;insn-&gt;off &gt; 1&amp;#39; was intended to ensure the offset is<br /> either 0, or 1 for BPF_MOD/BPF_DIV. However, because &amp;#39;insn-&gt;off&amp;#39; is<br /> signed, this check incorrectly accepts all negative values (e.g., -1).<br /> <br /> This commit tightens the validation by changing the condition to<br /> &amp;#39;(insn-&gt;off != 0 &amp;&amp; insn-&gt;off != 1)&amp;#39;. This ensures that any value<br /> other than the explicitly permitted 0 and 1 is rejected, hardening the<br /> verifier against malformed BPF programs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: use dst_dev_rcu() in sk_setup_caps()<br /> <br /> Use RCU to protect accesses to dst-&gt;dev from sk_setup_caps()<br /> and sk_dst_gso_max_size().<br /> <br /> Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),<br /> and ip_dst_mtu_maybe_forward().<br /> <br /> ip4_dst_hoplimit() can use dst_dev_net_rcu().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-fc: move lsop put work to nvmet_fc_ls_req_op<br /> <br /> It’s possible for more than one async command to be in flight from<br /> __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.<br /> <br /> In the current code, only one put work item is queued at a time, which<br /> results in a leaked reference.<br /> <br /> To fix this, move the work item to the nvmet_fc_ls_req_op struct, which<br /> already tracks all resources related to the command.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()<br /> <br /> Currently, if find_and_map_user_pages() takes a DMA xfer request from the<br /> user with a length field set to 0, or in a rare case, the host receives<br /> QAIC_TRANS_DMA_XFER_CONT from the device where resources-&gt;xferred_dma_size<br /> is equal to the requested transaction size, the function will return 0<br /> before allocating an sgt or setting the fields of the dma_xfer struct.<br /> In that case, encode_addr_size_pairs() will try to access the sgt which<br /> will lead to a general protection fault.<br /> <br /> Return an EINVAL in case the user provides a zero-sized ALP, or the device<br /> requests continuation after all of the bytes have been transferred.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ip6_tunnel: Prevent perpetual tunnel growth<br /> <br /> Similarly to ipv4 tunnel, ipv6 version updates dev-&gt;needed_headroom, too.<br /> While ipv4 tunnel headroom adjustment growth was limited in<br /> commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),<br /> ipv6 tunnel yet increases the headroom without any ceiling.<br /> <br /> Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.<br /> <br /> Credits to Francesco Ruggeri, who was originally debugging this issue<br /> and wrote local Arista-specific patch and a reproducer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Fix SMP ordering in switch_mm_irqs_off()<br /> <br /> Stephen noted that it is possible to not have an smp_mb() between<br /> the loaded_mm store and the tlb_gen load in switch_mm(), meaning the<br /> ordering against flush_tlb_mm_range() goes out the window, and it<br /> becomes possible for switch_mm() to not observe a recent tlb_gen<br /> update and fail to flush the TLBs.<br /> <br /> [ dhansen: merge conflict fixed by Ingo ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Harden userspace-supplied xdp_desc validation<br /> <br /> Turned out certain clearly invalid values passed in xdp_desc from<br /> userspace can pass xp_{,un}aligned_validate_desc() and then lead<br /> to UBs or just invalid frames to be queued for xmit.<br /> <br /> desc-&gt;len close to ``U32_MAX`` with a non-zero pool-&gt;tx_metadata_len<br /> can cause positive integer overflow and wraparound, the same way low<br /> enough desc-&gt;addr with a non-zero pool-&gt;tx_metadata_len can cause<br /> negative integer overflow. Both scenarios can then pass the<br /> validation successfully.<br /> This doesn&amp;#39;t happen with valid XSk applications, but can be used<br /> to perform attacks.<br /> <br /> Always promote desc-&gt;len to ``u64`` first to exclude positive<br /> overflows of it. Use explicit check_{add,sub}_overflow() when<br /> validating desc-&gt;addr (which is ``u64`` already).<br /> <br /> bloat-o-meter reports a little growth of the code size:<br /> <br /> add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)<br /> Function old new delta<br /> xskq_cons_peek_desc 299 330 +31<br /> xsk_tx_peek_release_desc_batch 973 1002 +29<br /> xsk_generic_xmit 3148 3132 -16<br /> <br /> but hopefully this doesn&amp;#39;t hurt the performance much.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/events: Return -EEXIST for bound VIRQs<br /> <br /> Change find_virq() to return -EEXIST when a VIRQ is bound to a<br /> different CPU than the one passed in. With that, remove the BUG_ON()<br /> from bind_virq_to_irq() to propogate the error upwards.<br /> <br /> Some VIRQs are per-cpu, but others are per-domain or global. Those must<br /> be bound to CPU0 and can then migrate elsewhere. The lookup for<br /> per-domain and global will probably fail when migrated off CPU 0,<br /> especially when the current CPU is tracked. This now returns -EEXIST<br /> instead of BUG_ON().<br /> <br /> A second call to bind a per-domain or global VIRQ is not expected, but<br /> make it non-fatal to avoid trying to look up the irq, since we don&amp;#39;t<br /> know which per_cpu(virq_to_irq) it will be in.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: zynqmp-ipi: Fix SGI cleanup on unbind<br /> <br /> The driver incorrectly determines SGI vs SPI interrupts by checking IRQ<br /> number

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails<br /> <br /> devm_kasprintf() may return NULL on memory allocation failure,<br /> but the debug message prints cpus-&gt;dai_name before checking it.<br /> Move the dev_dbg() call after the NULL check to prevent potential<br /> NULL pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/deadline: Stop dl_server before CPU goes offline<br /> <br /> IBM CI tool reported kernel warning[1] when running a CPU removal<br /> operation through drmgr[2]. i.e "drmgr -c cpu -r -q 1"<br /> <br /> WARNING: CPU: 0 PID: 0 at kernel/sched/cpudeadline.c:219 cpudl_set+0x58/0x170<br /> NIP [c0000000002b6ed8] cpudl_set+0x58/0x170<br /> LR [c0000000002b7cb8] dl_server_timer+0x168/0x2a0<br /> Call Trace:<br /> [c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable)<br /> [c0000000002b7cb8] dl_server_timer+0x168/0x2a0<br /> [c00000000034df84] __hrtimer_run_queues+0x1a4/0x390<br /> [c00000000034f624] hrtimer_interrupt+0x124/0x300<br /> [c00000000002a230] timer_interrupt+0x140/0x320<br /> <br /> Git bisects to: commit 4ae8d9aa9f9d ("sched/deadline: Fix dl_server getting stuck")<br /> <br /> This happens since:<br /> - dl_server hrtimer gets enqueued close to cpu offline, when<br /> kthread_park enqueues a fair task.<br /> - CPU goes offline and drmgr removes it from cpu_present_mask.<br /> - hrtimer fires and warning is hit.<br /> <br /> Fix it by stopping the dl_server before CPU is marked dead.<br /> <br /> [1]: https://lore.kernel.org/all/8218e149-7718-4432-9312-f97297c352b9@linux.ibm.com/<br /> [2]: https://github.com/ibm-power-utilities/powerpc-utils/tree/next/src/drmgr<br /> <br /> [sshegde: wrote the changelog and tested it]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: Fix using smp_processor_id() in preemptible code warnings<br /> <br /> Syzbot reported the following warning:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879<br /> caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331<br /> CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120<br /> check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49<br /> usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331<br /> usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708<br /> usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417<br /> __dev_set_mtu net/core/dev.c:9443 [inline]<br /> netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496<br /> netif_set_mtu+0xb0/0x160 net/core/dev.c:9520<br /> dev_set_mtu+0xae/0x170 net/core/dev_api.c:247<br /> dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572<br /> dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821<br /> sock_do_ioctl+0x19d/0x280 net/socket.c:1204<br /> sock_ioctl+0x42f/0x6a0 net/socket.c:1311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl fs/ioctl.c:892 [inline]<br /> __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> For historical and portability reasons, the netif_rx() is usually<br /> run in the softirq or interrupt context, this commit therefore add<br /> local_bh_disable/enable() protection in the usbnet_resume_rx().