Re: [PATCH] nvmet-fc: Fix potential Use-after-free bug in nvmet_fc_delete_target_queue()

[James Smart <jsmart2021@gmail.com>]

On 9/20/2022 5:54 AM, Liang He wrote:
> 
> At 2022-09-20 01:57:05, "James Smart" <jsmart2021@gmail.com> wrote:
>> On 9/18/2022 6:46 PM, Liang He wrote:
>>>>
>>>> 		kfree(deferfcp);
>>>>
>>>> -		spin_lock_irqsave(&queue->qlock, flags);
>>>> +		spin_lock_irqsave(q_lock, flags);
>>>> 	}
>>>> 	spin_unlock_irqrestore(&queue->qlock, flags);
>>>>
>>>> -- 
>>>> 2.25.1
>>>
>>> Sorry, my patch is totally wrong as the 'qlock' is embeded into queue.
>>> So if queue is freed, the 'qlock' will also be freed.
>>>
>>> Now, we can only hope the 'nvmet_fc_tgt_q_put' in lin 941 will never really free the 'queue'.
>>
>> Did you actually see that occur (line 941 freed the queue) ?
>>
>> -- james
> 
> Hi, James,
> 
> I actually have not seen this as I use static method to detect it.
> 
> While there will be no UAF in current version, I think we should not use the
> reference after we put it, right?
> 
> Liang

there are multiple gets thus puts for it. All depends on the heirarchy 
of what's happening. Have to track that through. Expectation, based on 
the implementation, is that wouldn't be the last reference so it 
wouldn't free it. now need to prove the truth of that.

-- james