CVE-2026-63949

auxdisplay: line-display: fix OOB read on zero-length message_store()

published July 19, 2026

CVSS
—
EPSS
0%
Percentile
6.3
In the wild
Unconfirmed
What it is

In the Linux kernel, the following vulnerability has been resolved:

auxdisplay: line-display: fix OOB read on zero-length message_store()

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]:

write(fd, "", 0);

-> message_store(..., buf, count=0)

-> linedisp_display(linedisp, buf, count=0)

-> msg[count - 1] == '\n' ; OOB read

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 '\n', the following count--

wraps ssize_t 0 to -1 and is then passed to kmemdup_nul().

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.

Guard the trailing-newline trim with a count check. The

existing if (!count) block then takes the clear-display path

unchanged.

Affects every auxdisplay driver that registers via

linedisp_register() / linedisp_attach(): ht16k33, max6959,

img-ascii-lcd, seg-led-gpio.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00172 · 6.3th percentile
Published
2026-07-19T14:55Z
EPSS history
Timeline
  • 19 JUL 14:55Z
    auxdisplay: line-display: fix OOB read on zero-length message_store()
    cvelistv5