[PATCH] nvmet-tcp: Fix a possible UAF in queue intialization setup
Sagi Grimberg
sagi at grimberg.me
Wed Oct 4 06:25:13 PDT 2023
>>> Hello,
>>>
>>> On Mon, 2 Oct 2023 13:54:28 +0300 Sagi Grimberg <sagi at 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 at gmail.com>
>>>> Tested-by: Alon Zahavi <zahavi.alon at gmail.com>
>>>> Signed-off-by: Sagi Grimberg <sagi at 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>
I could have sworn to have seen patches that did not have stable CCd
nor a Fixes tag and was picked up for stable kernels :)
But I guess those were either hallucinations or someone sending patches
to stable...
I can resend with CC to stable.
Thanks.
More information about the Linux-nvme
mailing list