Vulnerabilities

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.

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 ]

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().

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.

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.

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

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.

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]

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.

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)

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: No support of struct argument in trampoline programs<br /> <br /> The current implementation does not support struct argument. This causes<br /> a oops when running bpf selftest:<br /> <br /> $ ./test_progs -a tracing_struct<br /> Oops[#1]:<br /> CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938<br /> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:<br /> rcu: 1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801<br /> rcu: (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)<br /> Sending NMI from CPU 0 to CPUs 1:<br /> rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) -&gt;state=0x0 -&gt;cpu=2<br /> rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.<br /> rcu: RCU grace-period kthread stack dump:<br /> task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x00000800<br /> Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680<br /> 9000000085d88000 0000000000000000 0000000000000040 9000000087159350<br /> 9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005<br /> 00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004<br /> 9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e<br /> 00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350<br /> 900000008715bf98 0000000000000005 9000000087036000 900000008704a000<br /> 9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0<br /> 00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000<br /> 9000000007002150 00000000ffff355b 9000000084615480 0000000007000002<br /> ...<br /> Call Trace:<br /> [] __schedule+0x410/0x1520<br /> [] schedule+0x34/0x190<br /> [] schedule_timeout+0x98/0x140<br /> [] rcu_gp_fqs_loop+0x5f8/0x868<br /> [] rcu_gp_kthread+0x260/0x2e0<br /> [] kthread+0x144/0x238<br /> [] ret_from_kernel_thread+0x28/0xc8<br /> [] ret_from_kernel_thread_asm+0xc/0x88<br /> <br /> rcu: Stack dump where RCU GP kthread last ran:<br /> Sending NMI from CPU 0 to CPUs 2:<br /> NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4<br /> <br /> Reject it for now.