From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-80798: nfc: llcp: reject PDUs shorter than the LLCP header
Date: Fri, 4 Sep 2026 17:11:37 +0200 [thread overview]
Message-ID: <2026090408-CVE-2026-80798-9936@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: reject PDUs shorter than the LLCP header
Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the
receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes
before parsing it.
nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/
nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a
CONNECT or CC PDU then computes
tlv_array_len = skb->len - LLCP_HEADER_SIZE;
as a size_t and hands it to the TLV walk. When the frame is shorter than
the header the subtraction wraps to a huge value and the walk runs far
past the buffer, an out-of-bounds read.
A nearby NFC device can reach this without authentication; LLCP link
activation happens automatically after NFC-DEP.
Guard the common receive choke point __nfc_llcp_recv(), shared by both the
target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so
a short skb is dropped before the rx_work worker parses it. Use
pskb_may_pull() rather than a skb->len test so the two header bytes are
guaranteed to sit in the skb linear area even for a non-linear skb,
matching how the sibling NCI and HCI receive paths validate their headers.
Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on
linux-next.
Found by 0sec automated security-research tooling (https://0sec.ai).
The Linux kernel CVE team has assigned CVE-2026-80798 to this issue.
Affected and fixed versions
===========================
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 5.10.267 with commit e6ec76a68dce04884dfeccfe5a5f0e9f67c0ec82
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 5.15.218 with commit f36cffea24bf3e2cc29a00d4b51dbcadc087d810
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 6.1.185 with commit a7b9b449f5a5132221fff6adc11a9431ab8cd914
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 6.6.154 with commit 3793d768b40f38bb97265dd5b9a8b8655c4e1b1d
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 6.12.106 with commit eab47618e282602197db287ecbd1b09d356a2515
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 6.18.47 with commit e969e98410051b1ef8cc318bfe0c7e3f24ec766d
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 7.1.11 with commit ae5f20f5842f440b72d030e3a34fe182dd8eae42
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 7.2.1 with commit d3d90243393c48146911c67fd3792b549d21d9e6
Issue introduced in 3.3 with commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a and fixed in 7.3-rc1 with commit 95674f506c6376d6722a23144c9acd26609771ed
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-80798
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/nfc/llcp_core.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/e6ec76a68dce04884dfeccfe5a5f0e9f67c0ec82
https://git.kernel.org/stable/c/f36cffea24bf3e2cc29a00d4b51dbcadc087d810
https://git.kernel.org/stable/c/a7b9b449f5a5132221fff6adc11a9431ab8cd914
https://git.kernel.org/stable/c/3793d768b40f38bb97265dd5b9a8b8655c4e1b1d
https://git.kernel.org/stable/c/eab47618e282602197db287ecbd1b09d356a2515
https://git.kernel.org/stable/c/e969e98410051b1ef8cc318bfe0c7e3f24ec766d
https://git.kernel.org/stable/c/ae5f20f5842f440b72d030e3a34fe182dd8eae42
https://git.kernel.org/stable/c/d3d90243393c48146911c67fd3792b549d21d9e6
https://git.kernel.org/stable/c/95674f506c6376d6722a23144c9acd26609771ed
reply other threads:[~2026-09-04 15:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=2026090408-CVE-2026-80798-9936@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@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 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.