[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D7OOGIOAJRUH.9LOJ3X4IUKQV@bsdbackstore.eu>
Date: Mon, 10 Feb 2025 11:01:39 +0100
From: "Maurizio Lombardi" <mlombard@...backstore.eu>
To: "zhang.guanghui@...tc.cn" <zhang.guanghui@...tc.cn>, "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: nvme-tcp: fix a possible UAF when failing to send request
On Mon Feb 10, 2025 at 8:41 AM CET, zhang.guanghui@...tc.cn wrote:
> Hello
>
>
I guess you have to fix your mail client.
>
> When using the nvme-tcp driver in a storage cluster, the driver may trigger a null pointer causing the host to crash several times.
> By analyzing the vmcore, we know the direct cause is that the request->mq_hctx was used after free.
>
>
> CPU1 CPU2
>
> nvme_tcp_poll nvme_tcp_try_send --failed to send reqrest 13
This simply looks like a race condition between nvme_tcp_poll() and nvme_tcp_try_send()
Personally, I would try to fix it inside the nvme-tcp driver without
touching the core functions.
Maybe nvme_tcp_poll should just ensure that io_work completes before
calling nvme_tcp_try_recv(), the POLLING flag should then prevent io_work
from getting rescheduled by the nvme_tcp_data_ready() callback.
Maurizio
Powered by blists - more mailing lists