Vulnerabilidades

*** 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 /> 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 /> 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 /> media: nxp: imx8-isi: m2m: Fix streaming cleanup on release<br /> <br /> If streamon/streamoff calls are imbalanced, such as when exiting an<br /> application with Ctrl+C when streaming, the m2m usage_count will never<br /> reach zero and the ISI channel won&amp;#39;t be freed. Besides from that, if the<br /> input line width is more than 2K, it will trigger a WARN_ON():<br /> <br /> [ 59.222120] ------------[ cut here ]------------<br /> [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654<br /> [ 59.238569] Modules linked in: ap1302<br /> [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT<br /> [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT)<br /> [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120<br /> [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120<br /> [ 59.275047] sp : ffff8000848c3b40<br /> [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00<br /> [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001<br /> [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780<br /> [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000<br /> [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c<br /> [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30<br /> [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420<br /> [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000<br /> [ 59.349590] Call trace:<br /> [ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P)<br /> [ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c<br /> [ 59.361072] v4l_streamon+0x24/0x30<br /> [ 59.364556] __video_do_ioctl+0x40c/0x4a0<br /> [ 59.368560] video_usercopy+0x2bc/0x690<br /> [ 59.372382] video_ioctl2+0x18/0x24<br /> [ 59.375857] v4l2_ioctl+0x40/0x60<br /> [ 59.379168] __arm64_sys_ioctl+0xac/0x104<br /> [ 59.383172] invoke_syscall+0x48/0x104<br /> [ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0<br /> [ 59.391613] do_el0_svc+0x1c/0x28<br /> [ 59.394915] el0_svc+0x34/0xf4<br /> [ 59.397966] el0t_64_sync_handler+0xa0/0xe4<br /> [ 59.402143] el0t_64_sync+0x198/0x19c<br /> [ 59.405801] ---[ end trace 0000000000000000 ]---<br /> <br /> Address this issue by moving the streaming preparation and cleanup to<br /> the vb2 .prepare_streaming() and .unprepare_streaming() operations. This<br /> also simplifies the driver by allowing direct usage of the<br /> v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Check GuC running state before deregistering exec queue<br /> <br /> In normal operation, a registered exec queue is disabled and<br /> deregistered through the GuC, and freed only after the GuC confirms<br /> completion. However, if the driver is forced to unbind while the exec<br /> queue is still running, the user may call exec_destroy() after the GuC<br /> has already been stopped and CT communication disabled.<br /> <br /> In this case, the driver cannot receive a response from the GuC,<br /> preventing proper cleanup of exec queue resources. Fix this by directly<br /> releasing the resources when GuC is not running.<br /> <br /> Here is the failure dmesg log:<br /> "<br /> [ 468.089581] ---[ end trace 0000000000000000 ]---<br /> [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)<br /> [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535<br /> [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1<br /> [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1)<br /> [ 468.092716] ------------[ cut here ]------------<br /> [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]<br /> "<br /> <br /> v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().<br /> As CT may go down and come back during VF migration.<br /> <br /> (cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)