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
next prev 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®