kernel/linux.git, branch v7.0.9

Linux 7.0.9

2026-05-17T15:16:34+00:00

Link: https://lore.kernel.org/r/20260515154658.538039039@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Takeshi Ogasawara Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Salvatore Bonaccorso Tested-by: Brett A C Sheffield Tested-by: Justin M. Forbes Tested-by: Jeffrin Jose T Tested-by: Ron Economos Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/vcn4: Avoid overflow on msg bound check

2026-05-17T15:16:34+00:00

commit 65bce27ea6192320448c30267ffc17ffa094e713 upstream. As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: 0a78f2bac142 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: SDL Signed-off-by: Benjamin Cheng Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885) Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/vcn3: Avoid overflow on msg bound check

2026-05-17T15:16:34+00:00

commit e6e9faba8100628990cccd13f0f044a648c303cf upstream. As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: b193019860d6 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Cc: SDL Signed-off-by: Benjamin Cheng Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit db00257ac9e4a51eb2515aaea161a019f7125e10) Signed-off-by: Greg Kroah-Hartman

vsock/virtio: fix accept queue count leak on transport mismatch

2026-05-17T15:16:34+00:00

commit 52bcb57a4e8a0865a76c587c2451906342ae1b2d upstream. virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport. Fixes: c0cfa2d8a788 ("vsock: add multi-transports support") Signed-off-by: Dudu Lu Reviewed-by: Bobby Eshleman Reviewed-by: Luigi Leonardi Reviewed-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260413131409.19022-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman

vsock/virtio: fix empty payload in tap skb for non-linear buffers

2026-05-17T15:16:34+00:00

commit 3a3e3d90cbc79600544536723911657730759af3 upstream. For non-linear skbs, virtio_transport_build_skb() goes through virtio_transport_copy_nonlinear_skb() to copy the original payload in the new skb to be delivered to the vsockmon tap device. This manually initializes an iov_iter but does not set iov_iter.count. Since the iov_iter is zero-initialized, the copy length is zero and no payload is actually copied to the monitor interface, leaving data un-initialized. Fix this by removing the linear vs non-linear split and using skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as vhost-vsock already does. This handles both linear and non-linear skbs, properly initializes the iov_iter, and removes the now unused virtio_transport_copy_nonlinear_skb(). While touching this code, let's also check the return value of skb_copy_datagram_iter(), even though it's unlikely to fail. Fixes: 4b0bf10eb077 ("vsock/virtio: non-linear skb handling for tap") Reported-by: Yiqi Sun Signed-off-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Reviewed-by: Arseniy Krasnov Link: https://patch.msgid.link/20260508164411.261440-3-sgarzare@redhat.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman

vsock/virtio: fix length and offset in tap skb for split packets

2026-05-17T15:16:34+00:00

commit 5f344d809e015fba3709e5219428c00b8ac5d7df upstream. virtio_transport_build_skb() builds a new skb to be delivered to the vsockmon tap device. To build the new skb, it uses the original skb data length as payload length, but as the comment notes, the original packet stored in the skb may have been split in multiple packets, so we need to use the length in the header, which is correctly updated before the packet is delivered to the tap, and the offset for the data. This was also similar to what we did before commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") where we probably missed something during the skb conversion. Also update the comment above, which was left stale by the skb conversion and still mentioned a buffer pointer that no longer exists. Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Signed-off-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Reviewed-by: Arseniy Krasnov Link: https://patch.msgid.link/20260508164411.261440-2-sgarzare@redhat.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman

vsock: fix buffer size clamping order

2026-05-17T15:16:34+00:00

commit d114bfdc9b76bf93b881e195b7ec957c14227bab upstream. In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size. Fixes: b9f2b0ffde0c ("vsock: handle buffer_size sockopts in the core") Suggested-by: Stefano Garzarella Signed-off-by: Norbert Szetei Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/180118C5-8BCF-4A63-A305-4EE53A34AB9C@doyensec.com Signed-off-by: Jakub Kicinski Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman

mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()

2026-05-17T15:16:33+00:00

[ Upstream commit 619eab23e1ce7c97e54bfc5a417306d94b3f6f13 ] The mmap_prepare hook functionality includes the ability to invoke mmap_prepare() from the mmap() hook of existing 'stacked' drivers, that is ones which are capable of calling the mmap hooks of other drivers/file systems (e.g. overlayfs, shm). As part of the mmap_prepare action functionality, we deal with errors by unmapping the VMA should one arise. This works in the usual mmap_prepare case, as we invoke this action at the last moment, when the VMA is established in the maple tree. However, the mmap() hook passes a not-fully-established VMA pointer to the caller (which is the motivation behind the mmap_prepare() work), which is detached. So attempting to unmap a VMA in this state will be problematic, with the most obvious symptom being a warning in vma_mark_detached(), because the VMA is already detached. It's also unncessary - the mmap() handler will clean up the VMA on error. So to fix this issue, this patch propagates whether or not an mmap action is being completed via the compatibility layer or directly. If the former, then we do not attempt VMA cleanup, if the latter, then we do. This patch also updates the userland VMA tests to reflect the change. Link: https://lore.kernel.org/20260421102150.189982-1-ljs@kernel.org Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc") Signed-off-by: Lorenzo Stoakes Reported-by: syzbot+db390288d141a1dccf96@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e69734.050a0220.24bfd3.0027.GAE@google.com/ Cc: David Hildenbrand Cc: Jann Horn Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Pedro Falcato Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Lorenzo Stoakes Signed-off-by: Greg Kroah-Hartman

perf build: fix "argument list too long" in second location

2026-05-17T15:16:33+00:00

commit 97ab89686a9e5d087042dbe73604a32b3de72653 upstream Turns out that displaying "RM $^" via quiet_cmd_rm can also upset the shell and cause it to display "argument list too long". Trying to quote $^ doesn't help. In the end, *not* displaying the (potentially long) list of files is probably the right thing to do for a "quiet" message, anyway. Instead, let's display a count of how many files were removed. There is always V=1 if more detail is required. TEST linux/tools/perf/pmu-events/metric_test.log RM ...634 orphan file(s)... LD linux/tools/perf/util/perf-util-in.o Also move the comment regarding xargs before the rule, so it doesn't show up in the build output. Signed-off-by: Markus Mayer Reviewed-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

sched_ext: Skip tasks with stale task_rq in bypass_lb_cpu()

2026-05-17T15:16:33+00:00

commit da2d81b4118a74e65d2335e221a38d665902a98c upstream. bypass_lb_cpu() transfers tasks between per-CPU bypass DSQs without migrating them - task_cpu() only updates when the donee later consumes the task via move_remote_task_to_local_dsq(). If the LB timer fires again before consumption and the new DSQ becomes a donor, @p is still on the previous CPU and task_rq(@p) != donor_rq. @p can't be moved without its own rq locked. Skip such tasks. Fixes: 95d1df610cdc ("sched_ext: Implement load balancer for bypass mode") Cc: stable@vger.kernel.org # v6.19+ Reported-by: Chris Mason Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi [ arighi: replace donor_rq with rq, not present in v7.0.y ] Signed-off-by: Andrea Righi Signed-off-by: Greg Kroah-Hartman