<?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>Sun, 04 Oct 2026 07:57:36 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-63949 — auxdisplay: line-display: fix OOB read on zero-length message_store()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-63949</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;auxdisplay: line-display: fix OOB read on zero-length message_store()&lt;/p&gt;
&lt;p&gt;linedisp_display() unconditionally reads msg[count - 1] before
checking whether count is zero, so a write of zero bytes to the
message sysfs attribute hits msg[-1]:&lt;/p&gt;
&lt;p&gt;write(fd, &amp;#34;&amp;#34;, 0);&lt;/p&gt;
&lt;p&gt;-&amp;gt; message_store(..., buf, count=0)
	   -&amp;gt; linedisp_display(linedisp, buf, count=0)
	      -&amp;gt; msg[count - 1] == &amp;#39;\n&amp;#39;  ; OOB read&lt;/p&gt;
&lt;p&gt;The kernfs write buffer for that store is a 1-byte allocation
(kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0),
so msg[-1] is a 1-byte read before the slab object. On a
KASAN-enabled kernel this trips an out-of-bounds report and
panics; on stock kernels it silently reads adjacent slab data
and, if that byte happens to be &amp;#39;\n&amp;#39;, the following count--
wraps ssize_t 0 to -1 and is then passed to kmemdup_nul().&lt;/p&gt;
&lt;p&gt;linedisp_display() is reached from the message_store() sysfs
callback (drivers/auxdisplay/line-display.c message attribute,
mode 0644) and from the in-tree initial-message setup with
count == -1, so the OOB path is only userspace-triggerable via
zero-byte writes; vfs_write() does not short-circuit on
count == 0 and kernfs_fop_write_iter() dispatches the store
callback regardless.&lt;/p&gt;
&lt;p&gt;Guard the trailing-newline trim with a count check. The
existing if (!count) block then takes the clear-display path
unchanged.&lt;/p&gt;
&lt;p&gt;Affects every auxdisplay driver that registers via
linedisp_register() / linedisp_attach(): ht16k33, max6…&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;auxdisplay: line-display: fix OOB read on zero-length message_store()&lt;/p&gt;
&lt;p&gt;linedisp_display() unconditionally reads msg[count - 1] before
checking whether count is zero, so a write of zero bytes to the
message sysfs attribute hits msg[-1]:&lt;/p&gt;
&lt;p&gt;write(fd, &amp;#34;&amp;#34;, 0);&lt;/p&gt;
&lt;p&gt;-&amp;gt; message_store(..., buf, count=0)
	   -&amp;gt; linedisp_display(linedisp, buf, count=0)
	      -&amp;gt; msg[count - 1] == &amp;#39;\n&amp;#39;  ; OOB read&lt;/p&gt;
&lt;p&gt;The kernfs write buffer for that store is a 1-byte allocation
(kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0),
so msg[-1] is a 1-byte read before the slab object. On a
KASAN-enabled kernel this trips an out-of-bounds report and
panics; on stock kernels it silently reads adjacent slab data
and, if that byte happens to be &amp;#39;\n&amp;#39;, the following count--
wraps ssize_t 0 to -1 and is then passed to kmemdup_nul().&lt;/p&gt;
&lt;p&gt;linedisp_display() is reached from the message_store() sysfs
callback (drivers/auxdisplay/line-display.c message attribute,
mode 0644) and from the in-tree initial-message setup with
count == -1, so the OOB path is only userspace-triggerable via
zero-byte writes; vfs_write() does not short-circuit on
count == 0 and kernfs_fop_write_iter() dispatches the store
callback regardless.&lt;/p&gt;
&lt;p&gt;Guard the trailing-newline trim with a count check. The
existing if (!count) block then takes the clear-display path
unchanged.&lt;/p&gt;
&lt;p&gt;Affects every auxdisplay driver that registers via
linedisp_register() / linedisp_attach(): ht16k33, max6…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-63949</guid>
    </item>
  </channel>
</rss>
