kernel/git/stable/linux.git/drivers/vdpa, branch linux-rolling-lts

vdpa/mlx5: fix wrong list iterated in add_direct_chain error path

2026-09-14T11:36:04+00:00

[ Upstream commit 23ae56d9e74c122f95cae71ae3b9fc259fb88446 ] In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: Li RongQing Acked-by: Eugenio Pérez Reviewed-by: Dragos Tatulea Signed-off-by: Michael S. Tsirkin Message-ID: <20260701113608.1972-1-lirongqing@baidu.com> Signed-off-by: Sasha Levin

vdpa_sim: fix cleanup after worker creation failure

2026-09-14T11:36:03+00:00

[ Upstream commit bd670e5dfd2b01fd9692f61fa1456434c54026a4 ] vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance. Fixes: 76acfa7bc54f ("vdpa_sim: use kthread worker") Assisted-by: OpenAI-Codex:GPT-5 Reviewed-by: Eugenio Pérez Signed-off-by: Linfeng Sun Message-ID: <20260620100959.2070316-1-slf@hdu.edu.cn> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin

vdpa/mlx5: Fix buffer length in create_direct_keys()

2026-08-19T16:17:23+00:00

[ Upstream commit 727e1f569855df83579edbd73dcb4a0723543a12 ] We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120) So in essence we read 16 bytes beyond 4384-byte allocation. create_direct_keys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data. Properly calculate the input size to match the pointer and allocation size. Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel") Signed-off-by: Christian Borntraeger Tested-by: Dragos Tatulea Reviewed-by: Dragos Tatulea Signed-off-by: Michael S. Tsirkin Message-ID: <20260706141537.3510294-1-borntraeger@linux.ibm.com> Signed-off-by: Sasha Levin

VDUSE: avoid leaking information to userspace

2026-08-03T09:22:09+00:00

[ Upstream commit 9c1523803445ee0348f62b77793266dd981596e0 ] The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace. Fixes: 8c773d53fb7b ("vduse: Implement an MMU-based software IOTLB") Cc: stable@vger.kernel.org Signed-off-by: Jason Wang Reviewed-by: Xie Yongji Reviewed-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-ID: <20260130050750.4050-1-jasowang@redhat.com> Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

vduse: take out allocations from vduse_dev_alloc_coherent

2026-08-03T09:22:09+00:00

[ Upstream commit 489d76520612abf9a4ede4344349105406c91a73 ] The function vduse_dev_alloc_coherent will be called under rwlock in next patches. Make it out of the lock to avoid increasing its fail rate. Acked-by: Jason Wang Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-10-eperezma@redhat.com> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

vduse: remove unused vaddr parameter of vduse_domain_free_coherent

2026-08-03T09:22:09+00:00

[ Upstream commit 766e1749c0ef6a09651be9b8a8283d508c322b58 ] We will modify the function in next patches so let's clean it first. Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-9-eperezma@redhat.com> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

vduse: return internal vq group struct as map token

2026-08-03T09:22:08+00:00

[ Upstream commit 02e3f7ffe2906033da73b7c7ea8180b131d0cdbc ] Return the internal struct that represents the vq group as virtqueue map token, instead of the device. This allows the map functions to access the information per group. At this moment all the virtqueues share the same vq group, that only can point to ASID 0. This change prepares the infrastructure for actual per-group address space handling Acked-by: Jason Wang Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-5-eperezma@redhat.com> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter

2026-07-24T14:16:51+00:00

commit ae9c13b6fd79087cc5a216ee1649b6f012c2a238 upstream. There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Cc: stable@vger.kernel.org Signed-off-by: Zhang Tianci Reviewed-by: Xie Yongji Acked-by: Jason Wang Acked-by: Eugenio Pérez Acked-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-ID: <20260226115550.1814-3-zhangtianci.1997@bytedance.com> Signed-off-by: Greg Kroah-Hartman

vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler

2026-07-24T14:16:07+00:00

[ Upstream commit 0d21a1d6375a05274291e32c1ab7cd57dbb69513 ] Look up the IRQ index in oct_hw->irqs instead of assuming irq - irqs[0]. This supports non-contiguous IRQ numbers and avoids incorrect ring indexing when irqs[0] is not the base. Fixes: 26f8ce06af64 ("vdpa/octeon_ep: enable support for multiple interrupts per device") Signed-off-by: Srujana Challa Signed-off-by: Michael S. Tsirkin Message-ID: <20260224095226.1001151-5-schalla@marvell.com> Signed-off-by: Sasha Levin

vdpa/octeon_ep: Fix PF->VF mailbox data address calculation

2026-07-24T14:16:07+00:00

[ Upstream commit 74dc530f4c505d61f0f3620e59fe56c325ae3437 ] The mailbox address was computed assuming 1 ring per VF. Read the actual rings-per-VF from OCTEP_EPF_RINFO and use it when calculating OCTEP_PF_MBOX_DATA offsets, fixing VF initialization when rings per VF > 1. Fixes: 8b6c724cdab8 ("virtio: vdpa: vDPA driver for Marvell OCTEON DPU devices") Signed-off-by: Srujana Challa Signed-off-by: Michael S. Tsirkin Message-ID: <20260224095226.1001151-2-schalla@marvell.com> Signed-off-by: Sasha Levin