CVE-2026-63949

What it actually does

This is a Linux kernel out-of-bounds read in the auxdisplay line-display sysfs handler. A zero-byte write to the writable `message` sysfs attribute reaches `linedisp_display()` with `count == 0`, but the code reads `msg[count - 1]` before checking for zero length, causing a one-byte read before the allocated kernfs buffer. On KASAN/debug kernels this can trigger a slab out-of-bounds report and panic. On non-debug kernels it may silently read adjacent slab memory; if the adjacent byte is a newline, the length can underflow and be passed to a later allocation path, potentially causing kernel instability or denial of service. The userspace-triggerable path applies to auxdisplay drivers using the line-display framework, including `ht16k33`, `max6959`, `img-ascii-lcd`, and `seg-led-gpio`. Exploitation requires local ability to write to the affected sysfs attribute, which is typically root-writable unless permissions have been relaxed.

Why it matters to the business

The primary business risk is local denial of service on Linux systems that expose affected auxiliary display devices or drivers. A privileged local user, compromised service, misconfigured device permission, or container/workload with access to the relevant sysfs path could crash or destabilize the host. The risk is limited by the need for local sysfs write access and affected hardware or loaded drivers. Public exploitation maturity is currently listed as none, EPSS is very low, and it is not listed in CISA KEV or associated with ransomware campaigns, so this should generally be handled through normal kernel patch cycles unless affected drivers are present on critical or embedded systems.

How an attack unfolds

An attacker first needs local execution on a Linux system where an affected auxdisplay line-display driver is registered and exposes a writable `message` sysfs attribute. The attacker identifies the sysfs device node associated with a supported driver such as `ht16k33`, `max6959`, `img-ascii-lcd`, or `seg-led-gpio`. They then perform a zero-length write to the `message` attribute. Unlike many file write paths, the kernfs write path still invokes the sysfs store callback for a zero-byte write. The callback passes `count == 0` into `linedisp_display()`, which reads one byte before the allocated buffer. On debug kernels this is likely to produce a KASAN out-of-bounds report and panic. On stock kernels the read may appear harmless, but if the preceding byte is a newline, the code can underflow the length and pass an invalid size into subsequent memory allocation logic, potentially causing kernel errors or system instability. There is no indication from the provided data of remote exploitation, active exploitation, named threat actor use, or ransomware use.

How to fix it

Apply a vendor kernel update that includes the upstream fix for `auxdisplay: line-display: fix OOB read on zero-length message_store()`. No exact fixed package versions were provided, so use distribution/vendor advisories for the deployed kernel stream and confirm the patch is included. Where immediate patching is not possible, reduce exposure by unloading or blacklisting unused affected auxdisplay drivers such as `ht16k33`, `max6959`, `img-ascii-lcd`, and `seg-led-gpio`; removing access to affected hardware from untrusted workloads; and ensuring sysfs device permissions remain root-only and are not delegated to containers or non-privileged users. Reboot into the fixed kernel after installation, because kernel package installation alone does not remove exposure from the running kernel.

How to confirm the fix worked

Confirm the running kernel version and vendor build include the patch for the line-display zero-length `message_store()` handling issue. Verify the system has rebooted into the patched kernel, not merely installed it. Check whether affected modules are loaded using module inventory commands such as `lsmod` and whether relevant sysfs `message` attributes exist under `/sys`. Validate permissions on any exposed `message` attributes and confirm they are not writable by untrusted users, groups, containers, or device-management services. In a controlled non-production test environment only, a zero-byte write to the affected `message` attribute should no longer produce KASAN, slab, allocation, or kernel warning messages and should follow the clear-display path safely.

Typical attack path

1. Gain local code execution on a Linux system with an affected auxdisplay line-display driver loaded or available.
2. Locate a writable sysfs `message` attribute for a line-display-backed device.
3. Ensure the executing user or process has permission to write to that sysfs attribute, typically requiring root or relaxed device permissions.
4. Issue a zero-byte write to the `message` sysfs attribute.
5. Trigger the kernel line-display sysfs store path, causing `linedisp_display()` to read before the allocated buffer.
6. Cause a KASAN panic, kernel warning, allocation failure, or host instability depending on kernel configuration and adjacent slab contents.

How to detect it

Post-exploitation detection should focus on kernel telemetry and local write activity to auxdisplay sysfs attributes. Review `dmesg`, journald kernel logs, `/var/log/kern.log`, `/var/log/messages`, crash dumps, pstore records, and kernel panic logs for KASAN or slab out-of-bounds reports involving `linedisp_display()`, `message_store()`, or `drivers/auxdisplay/line-display.c`. On systems with auditd, eBPF, osquery, or endpoint telemetry that records file writes, search for writes to sysfs paths ending in `/message` under devices associated with auxdisplay drivers, especially suspicious zero-byte writes from shells, scripts, container runtimes, device-management agents, or unexpected processes. Because the trigger is a zero-length write, many conventional file-content logs will show no payload; process, path, syscall, and kernel error telemetry are more useful than content inspection. If a panic occurred, correlate the crash time with process execution history, sudo logs, container activity, and any udev or automation changes that may have granted write access to the sysfs node.

• linedisp_display
• message_store
• drivers/auxdisplay/line-display.c
• KASAN: slab-out-of-bounds
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in linedisp_display
• auxdisplay: line-display
• ht16k33
• max6959
• img-ascii-lcd
• seg-led-gpio
• /sys/bus/i2c/drivers/ht16k33
• /sys/bus/i2c/drivers/max6959
• /sys/class/auxdisplay
• /message

What your security team should do

• Inventory Linux systems for loaded or available auxdisplay line-display drivers, especially `ht16k33`, `max6959`, `img-ascii-lcd`, and `seg-led-gpio`.
• Prioritize patching systems where affected drivers are loaded, affected hardware is present, or sysfs device access is exposed to non-administrative users or workloads.
• Apply the vendor kernel update containing the upstream line-display fix and reboot into the fixed kernel.
• If patching is delayed, unload or blacklist unused affected auxdisplay modules and restrict access to associated sysfs device paths.
• Review container, device passthrough, udev, and group-permission configurations to ensure untrusted workloads cannot write to host sysfs `message` attributes.
• Monitor kernel logs for KASAN, slab out-of-bounds, allocation, or panic messages referencing `linedisp_display`, `message_store`, or `drivers/auxdisplay/line-display.c`.
• Treat confirmed exploitation primarily as a host integrity and availability event; investigate how the process obtained write access to the affected sysfs attribute.