<?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 12:10:39 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-80799 — nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-80799</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: fix OOB read and u8 offset wrap in TLV parsers&lt;/p&gt;
&lt;p&gt;nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain
three related bugs in their TLV parsing loops:&lt;/p&gt;
&lt;p&gt;1. &amp;#39;offset&amp;#39; is declared u8 but tlv_array_len is u16. When TLV data
   advances offset past 255 it silently wraps to zero, causing
   infinite loops or double-processing of buffer data.&lt;/p&gt;
&lt;p&gt;2. Before reading tlv[0] (type) and tlv[1] (length) there is no
   check that offset+2 &amp;lt;= tlv_array_len. A truncated TLV causes
   an OOB read of one byte past the buffer end.&lt;/p&gt;
&lt;p&gt;3. After reading the length field, the value bytes are accessed
   without checking offset+2+length &amp;lt;= tlv_array_len. A crafted
   length=0xFF on a short buffer causes up to 255 bytes of OOB
   read past the buffer end.&lt;/p&gt;
&lt;p&gt;Both functions are reachable without authentication via
nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes
directly into nfc_llcp_parse_gb_tlv() with no additional
validation.&lt;/p&gt;
&lt;p&gt;Fix all three issues by widening offset from u8 to u16 and adding
bounds checks for both the TLV header and value field before each
access.&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: fix OOB read and u8 offset wrap in TLV parsers&lt;/p&gt;
&lt;p&gt;nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain
three related bugs in their TLV parsing loops:&lt;/p&gt;
&lt;p&gt;1. &amp;#39;offset&amp;#39; is declared u8 but tlv_array_len is u16. When TLV data
   advances offset past 255 it silently wraps to zero, causing
   infinite loops or double-processing of buffer data.&lt;/p&gt;
&lt;p&gt;2. Before reading tlv[0] (type) and tlv[1] (length) there is no
   check that offset+2 &amp;lt;= tlv_array_len. A truncated TLV causes
   an OOB read of one byte past the buffer end.&lt;/p&gt;
&lt;p&gt;3. After reading the length field, the value bytes are accessed
   without checking offset+2+length &amp;lt;= tlv_array_len. A crafted
   length=0xFF on a short buffer causes up to 255 bytes of OOB
   read past the buffer end.&lt;/p&gt;
&lt;p&gt;Both functions are reachable without authentication via
nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes
directly into nfc_llcp_parse_gb_tlv() with no additional
validation.&lt;/p&gt;
&lt;p&gt;Fix all three issues by widening offset from u8 to u16 and adding
bounds checks for both the TLV header and value field before each
access.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-80799</guid>
    </item>
  </channel>
</rss>
