Re: [PATCH] nvmet-tcp: Fix a possible UAF in queue intialization setup

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Oct 04, 2023 at 12:41:30PM +0300, Sagi Grimberg wrote:
> 
> > Hello,
> > 
> > On Mon, 2 Oct 2023 13:54:28 +0300 Sagi Grimberg <sagi@grimberg.me> wrote:
> > 
> > >  From Alon:
> > > "Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel,
> > > a malicious user can cause a UAF and a double free, which may lead to
> > > RCE (may also lead to an LPE in case the attacker already has local
> > > privileges)."
> > > 
> > > Hence, when a queue initialization fails after the ahash requests are
> > > allocated, it is guaranteed that the queue removal async work will be
> > > called, hence leave the deallocation to the queue removal.
> > > 
> > > Also, be extra careful not to continue processing the socket, so set
> > > queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error.
> > > 
> > > Reported-by: Alon Zahavi <zahavi.alon@gmail.com>
> > > Tested-by: Alon Zahavi <zahavi.alon@gmail.com>
> > > Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
> > 
> > Would it be better to add Fixes: and Cc: stable lines?
> 
> This issue existed since the introduction of the driver, I am not sure
> it applies cleanly that far back...
> 
> I figured that the description and Reported-by tag will trigger stable
> kernel pick up...

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>