From: Liu Chao <liuc63@xiaopeng.com>
To: David Heidelberg <david@ixit.cz>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, Ilan Elias <ilane@ti.com>,
"John W . Linville" <linville@tuxdriver.com>,
oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Liu Chao <liuc63@xiaopeng.com>,
stable@vger.kernel.org
Subject: [PATCH net] nfc: nci: avoid unbounded skb allocation when max_pkt_payload_len is zero
Date: Sun, 13 Sep 2026 18:13:09 +0800 [thread overview]
Message-ID: <20260913101309.891633-1-liuc63@xiaopeng.com> (raw)
nci_queue_tx_data_frags() uses conn_info->max_pkt_payload_len as the
fragment size. When that value is zero, frag_len is always zero and
total_len never decreases. The loop then allocates skbs without bound:
none of them are freed inside the loop, they accumulate on frags_q, and
there is no cond_resched() in the loop body. A single sendmsg() can
therefore consume all allocatable memory, and on CONFIG_PREEMPT_NONE it
occupies the CPU long enough to trip the softlockup watchdog:
watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [kworker/3:1:57]
Workqueue: events rawsock_tx_work [nfc]
Call Trace:
nci_send_data+0x1ca/0x6b0 [nci]
nci_transceive+0xbb/0x170 [nci]
rawsock_tx_work+0xb5/0x1a0 [nfc]
max_pkt_payload_len is taken verbatim from controller-supplied fields,
with no check for zero:
ntf.c: conn_info->max_pkt_payload_len = ntf.max_data_pkt_payload_size;
rsp.c: conn_info->max_pkt_payload_len = rsp->max_ctrl_pkt_payload_len;
Reject the zero value in the fragmentation path rather than at the
assignment sites. nci_queue_tx_data_frags() is the only place that
loops, and nci_send_data() takes the non-fragmenting branch only for
skb->len <= max_pkt_payload_len, which for a zero limit means empty
skbs alone. Validating on assignment would not be sufficient either,
because nci_rf_disc_rsp_packet() allocates ndev->rf_conn_info with
devm_kzalloc(), so max_pkt_payload_len is already zero before any
notification arrives.
No legitimate configuration is known to be affected. Where the NCI
spec does mandate a zero Max Data Packet Payload Size -- the NFCEE
Direct RF Interface -- nci_rf_intf_activated_ntf_packet() takes the
"goto listen" shortcut, bypassing the assignment entirely.
Reproduced with CONFIG_NFC_VIRTUAL_NCI by injecting an
RF_INTF_ACTIVATED_NTF with max_data_pkt_payload_size set to 0 and then
sending a data frame on an AF_NFC SEQPACKET socket.
Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Liu Chao <liuc63@xiaopeng.com>
---
net/nfc/nci/data.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 4253edea5..b549cef7d 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -114,6 +114,11 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
goto exit;
}
+ if (!conn_info->max_pkt_payload_len) {
+ rc = -EPROTO;
+ goto exit;
+ }
+
__skb_queue_head_init(&frags_q);
while (total_len) {
base-commit: e6b6078ea1731b05b3b552497b3bce4bf8b014ae
--
2.50.1
next reply other threads:[~2026-09-13 10:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 10:13 Liu Chao [this message]
2026-09-14 11:08 ` netdev-bot+sashiko
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=20260913101309.891633-1-liuc63@xiaopeng.com \
--to=liuc63@xiaopeng.com \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=ilane@ti.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=oe-linux-nfc@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
/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®