CVE-2026-53385

What it actually does

This is a race condition in the Linux kernel virtual console screen device handling code. During a write to a vc_screen interface, the kernel temporarily releases console_lock while copying data from userspace, allowing the referenced virtual console structure to be freed or invalidated concurrently. Although the code revalidates the pointer after reacquiring the lock, it can still later call vcs_scr_updated() with a NULL vc_data pointer, causing a NULL pointer dereference in the notifier path, including vcs_notifier(). The most likely technical outcome is a local kernel crash or kernel oops, with potential system denial of service depending on kernel configuration such as panic_on_oops.

Why it matters to the business

Successful exploitation can crash affected Linux systems or destabilize workloads that rely on local virtual console functionality. The primary operational risk is denial of service, including unexpected host reboots, service interruption, failed jobs, or degraded availability on multi-user systems. The public exploitation signal is currently low: EPSS is 0.00132, it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no mature public exploit is indicated. However, because the flaw is in the kernel, patching should still be prioritized for systems where untrusted or low-privileged local users, containers with console-device access, kiosk sessions, lab environments, or shared compute users can interact with virtual console devices.

How an attack unfolds

An attacker needs local ability to interact with the Linux virtual console screen device path, typically through vcs/vcsa-style interfaces exposed under /dev. The attacker repeatedly performs writes to the console screen device while racing those writes against operations that switch, close, deallocate, or otherwise invalidate the associated virtual console. The vulnerable code drops console_lock during the userspace copy, creating a timing window in which the saved vc_data reference can become stale. After the lock is reacquired, the code may observe that the console is gone and exit the write loop, but then still calls the screen-update notifier using a NULL console pointer. That results in a kernel NULL pointer dereference in the notifier chain. In most practical scenarios this produces a kernel oops, crash, or reboot rather than data theft or privilege escalation.

How to fix it

Apply a Linux kernel update that includes the upstream fix adding a NULL check before calling vcs_scr_updated() after vcs_write() revalidation. Because no product-specific affected or fixed versions were provided, use the security advisories from the Linux distribution or kernel vendor for the exact patched kernel package. Where immediate patching is not possible, reduce exposure by limiting local access to virtual console screen devices, reviewing permissions on /dev/vcs*, /dev/vcsa*, and /dev/vcsu*, preventing untrusted users or containers from accessing host console devices, and disabling or restricting unnecessary virtual console functionality where operationally feasible. Mitigations should be treated as temporary; kernel replacement and reboot into the fixed kernel are required for full remediation.

How to confirm the fix worked

Confirm that systems are running a kernel build that contains the fix for the vc_screen vcs_write/vcs_scr_updated NULL pointer dereference. Validate using distribution package metadata, kernel changelogs, vendor security advisories, or by confirming the installed source includes a NULL check before invoking vcs_scr_updated() after the vcs_write() loop. After patch deployment, reboot hosts into the updated kernel and verify with uname -r and package manager output. Also confirm that untrusted local users and containers do not have write access to /dev/vcs*, /dev/vcsa*, or /dev/vcsu* unless explicitly required. Monitor kernel logs after remediation to ensure there are no recurring oops messages referencing vcs_notifier, vcs_scr_updated, or vcs_write.

Typical attack path

1. Gain local code execution or an interactive local session on an affected Linux system.
2. Identify whether virtual console screen devices such as /dev/vcs*, /dev/vcsa*, or /dev/vcsu* are present and writable by the attacker’s context.
3. Repeatedly write to the virtual console screen device while concurrently triggering virtual console lifecycle changes such as switching, closing, resetting, or deallocating consoles.
4. Win the race condition while console_lock is released during copy_from_user-style handling.
5. Cause the kernel to call vcs_scr_updated() with a NULL vc_data pointer.
6. Trigger a NULL pointer dereference in vcs_notifier(), resulting in a kernel oops, crash, or system reboot depending on configuration.

How to detect it

To determine whether the issue may already have been triggered, review kernel, system, and crash logs for NULL pointer dereferences or kernel oops events involving the virtual console screen subsystem. Relevant sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg captures, crash dump infrastructure such as kdump/vmcore, and endpoint telemetry that records kernel panics or unexpected reboots. Focus on stack traces mentioning vcs_notifier, vcs_scr_updated, vcs_write, vc_screen, or KASAN NULL pointer dereference. Also look for repeated writes or abnormal access to /dev/vcs*, /dev/vcsa*, or /dev/vcsu* shortly before a crash, especially by non-administrative users, interactive sessions, or containerized processes. Absence of these artifacts does not prove non-exploitation because kernel oops logs may be lost after reboot if persistent journaling or crash dumps are not enabled.

• BUG: KASAN: null-ptr-deref in vcs_notifier
• KASAN: null-ptr-deref in vcs_notifier
• NULL pointer dereference in vcs_notifier
• vcs_notifier+
• vcs_scr_updated
• vcs_write
• vc_screen
• /dev/vcs
• /dev/vcs1
• /dev/vcsa
• /dev/vcsa1
• /dev/vcsu
• Oops:
• kernel BUG at drivers/tty/vt/vc_screen.c
• RIP: 0010:vcs_notifier
• Call Trace:
• panic_on_oops

What your security team should do

• Inventory Linux systems that expose virtual console screen devices and prioritize shared, multi-user, kiosk, lab, desktop, bastion, and container-host systems where local users may have access.
• Patch affected systems through the operating system vendor’s kernel update channel and reboot into the fixed kernel.
• If patching is delayed, restrict permissions and device exposure for /dev/vcs*, /dev/vcsa*, and /dev/vcsu*, especially in container runtimes and multi-user environments.
• Search historical kernel logs for crashes or oops traces involving vcs_notifier(), vcs_scr_updated(), vcs_write(), vc_screen, or NULL pointer dereference messages.
• Review kernel panic behavior such as panic_on_oops because enabling panic on oops can turn this bug into a reliable host reboot condition.
• Treat current urgency as moderate unless local untrusted users can access console devices; EPSS is low, there is no KEV listing, no known ransomware use, and no mature public exploit indicated.