[PATCH] RDMA/mlx4: Use the right list member in push_deleteing_req()

[PATCH] RDMA/mlx4: Use the right list member in push_deleteing_req()

[Ziheng Wei]

push_deleteing_req() looks up the last pending request from
group->func[slave].pending, but recovers the enclosing struct with the
group_list member instead of func_list.

A struct mcast_req is queued on two lists at once by queue_req():
group_list links it into group->pending_list and func_list links it
into group->func[].pending. The two list_head members are adjacent but
not at the same offset, so list_entry() on a node taken from
func[].pending yields a pointer 16 bytes past the start of the object.

The following pend_req->clean then reads past the end of the
allocation. On x86_64, sizeof(struct mcast_req) is 312 bytes and clean
is at offset 304; the shifted pointer reads it at offset 320.

The entry stays on the list when clear_pending_reqs() fails to cancel
group->timeout_work for the first request, which sets clear to 0 and
leaves the request queued. push_deleteing_req() is then called right
afterwards from clean_vf_mcast() and reads the bogus clean field, which
decides whether the new delete request is dropped.

Use func_list to recover the request.

Found by LLM-assisted source review. Not tested on SR-IOV hardware.
With a test module that calls clean_vf_mcast() on a fabricated group,
push_deleteing_req() read a marker value placed right after the
pending request and dropped the new delete request.

Fixes: b9c5d6a64358 ("IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV")
Cc: stable@vger.kernel.org
Signed-off-by: Ziheng Wei <zihengw03@163.com>
---

Notes:
    The changelog was drafted with an AI assistant from my analysis;
    I have reviewed the code, the fix and the text.

 drivers/infiniband/hw/mlx4/mcg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx4/mcg.c b/drivers/infiniband/hw/mlx4/mcg.c
index bba178ffe..8705724c8 100644
--- a/drivers/infiniband/hw/mlx4/mcg.c
+++ b/drivers/infiniband/hw/mlx4/mcg.c
@@ -1216,7 +1216,7 @@ static int push_deleteing_req(struct mcast_group *group, int slave)
 		return -ENOMEM;
 
 	if (!list_empty(&group->func[slave].pending)) {
-		pend_req = list_entry(group->func[slave].pending.prev, struct mcast_req, group_list);
+		pend_req = list_entry(group->func[slave].pending.prev, struct mcast_req, func_list);
 		if (pend_req->clean) {
 			kfree(req);
 			return 0;

base-commit: 97d73c8251226cf27cc6656b4c542869bb8c69fa
-- 
2.43.0

Re: [PATCH] RDMA/mlx4: Use the right list member in push_deleteing_req()

[sashiko-bot]

> push_deleteing_req() looks up the last pending request from
> group->func[slave].pending, but recovers the enclosing struct with the
> group_list member instead of func_list.
> 
> A struct mcast_req is queued on two lists at once by queue_req():
> group_list links it into group->pending_list and func_list links it
> into group->func[].pending. The two list_head members are adjacent but
> not at the same offset, so list_entry() on a node taken from
> func[].pending yields a pointer 16 bytes past the start of the object.
> 
> The following pend_req->clean then reads past the end of the
> allocation. On x86_64, sizeof(struct mcast_req) is 312 bytes and clean
> is at offset 304; the shifted pointer reads it at offset 320.
> 
> The entry stays on the list when clear_pending_reqs() fails to cancel
> group->timeout_work for the first request, which sets clear to 0 and
> leaves the request queued. push_deleteing_req() is then called right
> afterwards from clean_vf_mcast() and reads the bogus clean field, which
> decides whether the new delete request is dropped.
> 
> Use func_list to recover the request.
> 
> Found by LLM-assisted source review. Not tested on SR-IOV hardware.
> With a test module that calls clean_vf_mcast() on a fabricated group,
> push_deleteing_req() read a marker value placed right after the
> pending request and dropped the new delete request.
> 
> Fixes: b9c5d6a64358 ("IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ziheng Wei <zihengw03@163.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115080226.910258-1-zihengw03@163.com?part=1