All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuchao Zhang <ndaugoing@gmail.com>
To: David Heidelberg <david@ixit.cz>
Cc: "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Yuchao Zhang <ndaugoing@gmail.com>
Subject: [PATCH 0/1] nfc: llcp: reject connect() on sockets not in LLCP_CLOSED state
Date: Fri, 18 Sep 2026 11:39:19 +0800	[thread overview]
Message-ID: <20260918033920.85025-1-ndaugoing@gmail.com> (raw)

This patch addresses a socket state validation gap in NFC LLCP socket
connection logic where connect() can be invoked on sockets in the
LLCP_BOUND (or LLCP_LISTEN) state.

Historical background and context:
Earlier patches addressing CVE-2020-25670 / CVE-2020-25673 added an
explicit check for the LLCP_CONNECTING state in llcp_sock_connect() to
prevent duplicate in-flight connection requests on non-blocking sockets
from linking the socket multiple times into local->connecting_sockets.

However, that check implicitly assumed that any socket that was neither
LLCP_CONNECTED nor LLCP_CONNECTING was in LLCP_CLOSED. It omitted the
possibility that a socket had already been bound via llcp_sock_bind(),
which transitions the socket to LLCP_BOUND and adds it to local->sockets.

Vulnerability impact:
When connect() is called on an already bound socket:
1. llcp_sock_connect() overwrites llcp_sock->dev and llcp_sock->local
   without dropping the original references, causing refcount and memory
   leaks (service_name).
2. The socket is added to local->connecting_sockets while still remaining
   linked in local->sockets.
3. Upon receiving connection confirmation (CC), nfc_llcp_recv_cc() unlinks
   the socket from connecting_sockets and links it into local->sockets.
   Because the head of local->sockets still pointed to the socket itself,
   hlist_add_head() links the node to itself (node->next = node), forming
   an infinite loop. Subsequent traversals of local->sockets (e.g. during
   lookup or release) loop indefinitely under spinlock, leading to kernel
   soft-lockups and RCU stalls.
4. If connect() targets a different device index, the socket becomes linked
   across two different NFC devices, causing cross-device socket confusion.

Fix:
Enforce that sockets must be in LLCP_CLOSED before initiating a connection,
returning -EBADFD otherwise, aligning with the state check behavior in
llcp_sock_bind() and llcp_raw_sock_bind().

Tested and confirmed style-compliant with checkpatch.pl
(0 errors, 0 warnings).

Yuchao Zhang (1):
  nfc: llcp: reject connect() on sockets not in LLCP_CLOSED state

 net/nfc/llcp_sock.c | 4 ++++
 1 file changed, 4 insertions(+)

-- 
2.53.0


             reply	other threads:[~2026-09-18  3:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  3:39 Yuchao Zhang [this message]
2026-09-18  3:39 ` [PATCH 1/1] nfc: llcp: reject connect() on sockets not in LLCP_CLOSED state Yuchao Zhang
2026-09-21 14:08   ` Simon Horman

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=20260918033920.85025-1-ndaugoing@gmail.com \
    --to=ndaugoing@gmail.com \
    --cc=davem@davemloft.net \
    --cc=david@ixit.cz \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oe-linux-nfc@lists.linux.dev \
    --cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.