Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fc76b5ffbcd1855cdfdb3ad8973ed313decb2868.camel@redhat.com>
Subject: Re: [PATCH v2] nfc: llcp: Fix race in handling llcp_devices
From:   Paolo Abeni <pabeni@redhat.com>
To:     Wang ShaoBo <bobo.shaobowang@huawei.com>
Cc:     liwei391@huawei.com, sameo@linux.intel.com, kuba@kernel.org,
        davem@davemloft.net, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date:   Tue, 06 Dec 2022 12:09:21 +0100
In-Reply-To: <20221203071218.3817593-1-bobo.shaobowang@huawei.com>
References: <20221203071218.3817593-1-bobo.shaobowang@huawei.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hello,

On Sat, 2022-12-03 at 15:12 +0800, Wang ShaoBo wrote:
> @@ -282,9 +285,13 @@ struct nfc_llcp_local *nfc_llcp_find_local(struct nfc_dev *dev)
>  {
>  	struct nfc_llcp_local *local;
>  
> +	spin_lock(&llcp_devices_list_lock);
>  	list_for_each_entry(local, &llcp_devices, list)
> -		if (local->dev == dev)
> +		if (local->dev == dev) {
> +			spin_unlock(&llcp_devices_list_lock);

I'm sorry for not noticing the above earlier, but it looks like this is
not enough. At this point local_release() may kick in and free 'local':
the caller will experience UaF. 

You could acquire a reference here and let the caller release it.

If the above race is not possible due to some other safeguards, it
should at least be documented clearly here.

Thanks,

Paolo