[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025032817241899538928@cestc.cn>
Date: Fri, 28 Mar 2025 17:24:19 +0800
From: "zhang.guanghui@...tc.cn" <zhang.guanghui@...tc.cn>
To: "Maurizio Lombardi" <mlombard@...backstore.eu>,
sagi <sagi@...mberg.me>,
mgurtovoy <mgurtovoy@...dia.com>,
kbusch <kbusch@...nel.org>,
sashal <sashal@...nel.org>,
chunguang.xu <chunguang.xu@...pee.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
linux-nvme <linux-nvme@...ts.infradead.org>,
linux-block <linux-block@...r.kernel.org>
Subject: Re: Re: nvme-tcp: fix a possible UAF when failing to send request
Hi,
So far, the UAF issue have not been occcurred during testing this patch in the same situation.
Additionally, the patch triggers a compilation warning, nvme_tcp_fail_request is declared but not defined, please also review.
Thanks
zhang.guanghui@...tc.cn
发件人: Maurizio Lombardi
发送时间: 2025-03-11 18:52
收件人: zhang.guanghui@...tc.cn; sagi; mgurtovoy; kbusch; sashal; chunguang.xu
抄送: linux-kernel; linux-nvme; linux-block
主题: Re: nvme-tcp: fix a possible UAF when failing to send request【请注意,邮件由sagigrim@...il.com代发】
On Fri Mar 7, 2025 at 11:10 AM CET, zhang.guanghui@...tc.cn wrote:
>
> Hi
>
> After testing this patch, sending request failure occurred, unfortunately, the issue still persists.
Maybe I am completely wrong but I am still quite convinced that the problem here
is that, despite the nvme_tcp_try_send() failure, the target sends a response capsule
for the command, leading to a double-completion in the host.
Sagi, what about taking this patch: https://lore.kernel.org/linux-nvme/20250306160322.1370300-2-mlombard@redhat.com/T/#u
and do a step further by not completing the request, leaving the error
recovery handler the task of cleaning everything up?
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 327f3f2f5399..72c1d7948386 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1328,8 +1328,8 @@ static int nvme_tcp_try_send(struct nvme_tcp_queue *queue)
} else if (ret < 0) {
dev_err(queue->ctrl->ctrl.device,
"failed to send request %d\n", ret);
- nvme_tcp_fail_request(queue->request);
nvme_tcp_done_send_req(queue);
+ nvme_tcp_error_recovery(&queue->ctrl->ctrl);
}
out:
memalloc_noreclaim_restore(noreclaim_flag);
Maurizio
Powered by blists - more mailing lists