<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 02:59:25 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-80798 — nfc: llcp: reject PDUs shorter than the LLCP header</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-80798</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nfc: llcp: reject PDUs shorter than the LLCP header&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/
nfc_llcp_ssap(), which dereference pdu-&amp;gt;data[0] and pdu-&amp;gt;data[1], and a
CONNECT or CC PDU then computes&lt;/p&gt;
&lt;p&gt;tlv_array_len = skb-&amp;gt;len - LLCP_HEADER_SIZE;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;A nearby NFC device can reach this without authentication; LLCP link
activation happens automatically after NFC-DEP.&lt;/p&gt;
&lt;p&gt;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-&amp;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.&lt;/p&gt;
&lt;p&gt;Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on
linux-next.&lt;/p&gt;
&lt;p&gt;Found by 0sec automated security-research tooling (https://0sec.ai).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nfc: llcp: reject PDUs shorter than the LLCP header&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/
nfc_llcp_ssap(), which dereference pdu-&amp;gt;data[0] and pdu-&amp;gt;data[1], and a
CONNECT or CC PDU then computes&lt;/p&gt;
&lt;p&gt;tlv_array_len = skb-&amp;gt;len - LLCP_HEADER_SIZE;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;A nearby NFC device can reach this without authentication; LLCP link
activation happens automatically after NFC-DEP.&lt;/p&gt;
&lt;p&gt;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-&amp;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.&lt;/p&gt;
&lt;p&gt;Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on
linux-next.&lt;/p&gt;
&lt;p&gt;Found by 0sec automated security-research tooling (https://0sec.ai).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-80798</guid>
    </item>
  </channel>
</rss>
