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

[Sagi Grimberg]

>>   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() ?

Its also the opposite of nvmet_tcp_alloc_crypto. Possible to fold both
but I think its also fine to keep.

> 
> Irrespective of that looks good to me.
> 
> Reviewed-by: Chaitanya Kulkarni <kch at nvidia.com>

Thanks