CVE-2026-63949

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> auxdisplay: line-display: fix OOB read on zero-length message_store()<br /> <br /> linedisp_display() unconditionally reads msg[count - 1] before<br /> checking whether count is zero, so a write of zero bytes to the<br /> message sysfs attribute hits msg[-1]:<br /> <br /> write(fd, "", 0);<br /> <br /> -&gt; message_store(..., buf, count=0)<br /> -&gt; linedisp_display(linedisp, buf, count=0)<br /> -&gt; msg[count - 1] == &amp;#39;\n&amp;#39; ; OOB read<br /> <br /> The kernfs write buffer for that store is a 1-byte allocation<br /> (kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0),<br /> so msg[-1] is a 1-byte read before the slab object. On a<br /> KASAN-enabled kernel this trips an out-of-bounds report and<br /> panics; on stock kernels it silently reads adjacent slab data<br /> and, if that byte happens to be &amp;#39;\n&amp;#39;, the following count--<br /> wraps ssize_t 0 to -1 and is then passed to kmemdup_nul().<br /> <br /> linedisp_display() is reached from the message_store() sysfs<br /> callback (drivers/auxdisplay/line-display.c message attribute,<br /> mode 0644) and from the in-tree initial-message setup with<br /> count == -1, so the OOB path is only userspace-triggerable via<br /> zero-byte writes; vfs_write() does not short-circuit on<br /> count == 0 and kernfs_fop_write_iter() dispatches the store<br /> callback regardless.<br /> <br /> Guard the trailing-newline trim with a count check. The<br /> existing if (!count) block then takes the clear-display path<br /> unchanged.<br /> <br /> Affects every auxdisplay driver that registers via<br /> linedisp_register() / linedisp_attach(): ht16k33, max6959,<br /> img-ascii-lcd, seg-led-gpio.