<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T11:05:18.570865+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-80798</id>
    <title>CVE-2026-80798 — nfc: llcp: reject PDUs shorter than the LLCP header</title>
    <updated>2026-09-30T11:05:18.731541+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>nfc: llcp: reject PDUs shorter than the LLCP header</p>
<p>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.</p>
<p>nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/
nfc_llcp_ssap(), which dereference pdu-&gt;data[0] and pdu-&gt;data[1], and a
CONNECT or CC PDU then computes</p>
<p>tlv_array_len = skb-&gt;len - LLCP_HEADER_SIZE;</p>
<p>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.</p>
<p>A nearby NFC device can reach this without authentication; LLCP link
activation happens automatically after NFC-DEP.</p>
<p>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-&gt;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.</p>
<p>Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on
linux-next.</p>
<p>Found by 0sec automated security-research tooling (https://0sec.ai).</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-80798"/>
  </entry>
</feed>
