mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Siddh Raman Pant <code@siddh.me>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Suman Ghosh <sumang@marvell.com>, netdev <netdev@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	syzbot+bbe84a4010eeea00982d 
	<syzbot+bbe84a4010eeea00982d@syzkaller.appspotmail.com>
Subject: Re: [PATCH net-next v3 1/2] nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local
Date: Tue, 5 Dec 2023 18:27:28 +0100	[thread overview]
Message-ID: <d41ea6ff-3c29-4a76-833d-19e6a6649d3c@linaro.org> (raw)
In-Reply-To: <18c3aff94ef.7cc78f6896702.921153651485959341@siddh.me>

On 05/12/2023 18:21, Siddh Raman Pant wrote:
> On Tue, 05 Dec 2023 22:10:00 +0530, Krzysztof Kozlowski wrote:
>>> @@ -180,6 +183,7 @@ int nfc_llcp_local_put(struct nfc_llcp_local *local)
>>>  	if (local == NULL)
>>>  		return 0;
>>>  
>>> +	nfc_put_device(local->dev);
>>
>> Mismatched order with get. Unwinding is always in reversed order. Or
>> maybe other order is here on purpose? Then it needs to be explained.
> 
> Yes, local_release() will free local, so local->dev cannot be accessed.
> Will add a comment.

So the problem is just storing the pointer? That's not really the valid
reason.

> 
>>> @@ -959,8 +963,18 @@ static void nfc_llcp_recv_connect(struct nfc_llcp_local *local,
>>>  	}
>>>  
>>>  	new_sock = nfc_llcp_sock(new_sk);
>>> -	new_sock->dev = local->dev;
>>> +
>>>  	new_sock->local = nfc_llcp_local_get(local);
>>> +	if (!new_sock->local) {
>>
>> There is already an cleanup path/label, so extend it. Existing code
>> needs some improvements in that matter as well.
> 
> Sure.
> 
>>> +		reason = LLCP_DM_REJ;
>>> +		release_sock(&sock->sk);
>>> +		sock_put(&sock->sk);
>>> +		sock_put(&new_sock->sk);
>>> +		nfc_llcp_sock_free(new_sock);
>>> +		goto fail;
>>> +	}
>>> +
>>> +	new_sock->dev = local->dev;
>>>  	new_sock->rw = sock->rw;
>>>  	new_sock->miux = sock->miux;
>>>  	new_sock->nfc_protocol = sock->nfc_protocol;
>>> @@ -1597,7 +1611,13 @@ int nfc_llcp_register_device(struct nfc_dev *ndev)
>>>  	if (local == NULL)
>>>  		return -ENOMEM;
>>>  
>>> -	local->dev = ndev;
>>> +	/* Hold a reference to the device. */
>>
>> That's obvious. Instead write something not obvious - why you call
>> nfc_get_device() while not incrementing reference to llcp_local.
> 
> Should I move it after kref_init()? Here, I'm bailing out early so we
> don't have to do unnecessary init first, and the rest of the function
> will never fail.

I meant, comment is obvious.

> 
>>> +	local->dev = nfc_get_device(ndev->idx);
>>
>> This looks confusing. If you can access ndev->idx, then ndev reference
>> was already increased. In such case iterating through all devices to
>> find it, is unnecessary and confusing.
> 
> I agree, it was something I thought about as well. There should be a
> new function for refcount increment. Maybe the existing one could be
> renamed to nfc_get_device_from_idx() and a new nfc_get_device() be
> defined.
> 
> I didn't want to introduce improvement patches in this UAF series, as
> that would be an independent unit of change.

Best regards,
Krzysztof


  parent reply	other threads:[~2023-12-05 17:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 13:08 [PATCH net-next v3 0/2] nfc: Fix UAF during datagram sending caused by missing refcounting Siddh Raman Pant
2023-12-04 13:08 ` [PATCH net-next v3 1/2] nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local Siddh Raman Pant
2023-12-05 11:04   ` [EXT] " Suman Ghosh
2023-12-05 16:40   ` Krzysztof Kozlowski
2023-12-05 17:21     ` Siddh Raman Pant
2023-12-05 17:24       ` Siddh Raman Pant
2023-12-05 17:27       ` Krzysztof Kozlowski [this message]
2023-12-05 18:01         ` Siddh Raman Pant
2023-12-06  8:48           ` Krzysztof Kozlowski
2023-12-04 13:08 ` [PATCH net-next v3 2/2] nfc: Do not send datagram if socket state isn't LLCP_BOUND Siddh Raman Pant
2023-12-05 11:04   ` [EXT] " Suman Ghosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d41ea6ff-3c29-4a76-833d-19e6a6649d3c@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=code@siddh.me \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sumang@marvell.com \
    --cc=syzbot+bbe84a4010eeea00982d@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®