netdev - Re: [PATCH v2 1/2] nfc: llcp: avoid double release/put on LLCP_CLOSED in nfc_llcp_recv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <69a6d938-e576-44cf-bcac-e86f30f24cb2@kernel.org>
Date: Thu, 18 Dec 2025 11:22:51 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: くさあさ <pioooooooooip@...il.com>
Cc: linux-nfc@...ts.01.org, Paolo Abeni <pabeni@...hat.com>,
 Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Simon Horman <horms@...nel.org>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] nfc: llcp: avoid double release/put on LLCP_CLOSED
 in nfc_llcp_recv_disc()

On 17/12/2025 14:05, くさあさ wrote:
> Hi Krzysztof,
> 
> Sorry about that — my previous response might not have made it to the
> list/thread.
> Replying here to address your concerns before sending v3.
> 
> 1) DM_DISC reply after LLCP_CLOSED
> This is not a new behavior introduced by my change. In the old code, the
> LLCP_CLOSED branch did release_sock() and nfc_llcp_sock_put(), but it did not
> return/goto, so execution continued and still reached nfc_llcp_send_dm(...,
> LLCP_DM_DISC) afterwards. The disc patch only removes the redundant
> CLOSED-branch
> cleanup so release_sock()/nfc_llcp_sock_put() are performed exactly once via the
> common exit path, while keeping the existing DM_DISC reply behavior.

I understand that you did not change the flow. I did not claim you did.
I ask why do you think your code is correct.

Do not top post and do not send new versions while the discussion is
still going.
> 
> 2) Initial refcount / double free concern
> nfc_llcp_recv_disc()/recv_hdlc() take an extra reference via nfc_llcp_sock_get()
> (sock_hold()). The issue is the mismatched put/unlock: the CLOSED branch drops
> the reference and releases the lock, and then the common exit path does the same
> again. This is a refcount/locking imbalance regardless of whether it immediately
> frees the object, and it may become a UAF depending on timing/refcounting.

You did not really address the problem. The refcnt has imbalance only if
you assume initial refcnt was 0.

Best regards,
Krzysztof