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

[Chaitanya Kulkarni]

On 10/2/2023 3:54 AM, Sagi Grimberg 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 at gmail.com>
> Tested-by: Alon Zahavi <zahavi.alon at gmail.com>
> Signed-off-by: Sagi Grimberg <sagi at grimberg.me>
> ---

Prior to this patch nvmet_tcp_free_crypto has only two callers [1],
does it makes sense to in-line nvmet_tcp_free_crypto() in only
remaining caller nvmet_tcp_release_queue_work() ?

Irrespective of that looks good to me.

Reviewed-by: Chaitanya Kulkarni <kch at nvidia.com>

-ck

[1]

1 tcp.c nvmet_tcp_handle_icreq        920 nvmet_tcp_free_crypto(queue); 

2 tcp.c nvmet_tcp_release_queue_work 1499 nvmet_tcp_free_crypto(queue);