CVE-2026-53402

What it actually does

This is a local Linux kernel information-disclosure flaw in the framebuffer console font handling path. A privileged local user able to change virtual terminal console fonts can trigger an error path in fbcon_do_set_font(), such as by causing vc_resize() to fail under memory pressure. The rollback path restores the font character count but does not restore the high-font state, leaving vc_hi_font_mask and the console screen buffer inconsistent. After that desynchronization, the virtual terminal layer may accept character indexes above 255 while rendering uses a reverted 256-character font table, causing fbcon_putcs() to perform an out-of-bounds read. The primary impact is kernel memory disclosure; the CVSS vector also reflects potential availability impact if the corrupted console state causes instability or crashes.

Why it matters to the business

Systems that expose Linux virtual terminals and framebuffer console functionality could allow a local authenticated user to read sensitive kernel memory or destabilize the host. In practical terms, this may help an attacker escalate a broader intrusion by leaking kernel addresses, secrets, or data useful for bypassing exploit mitigations. The issue is not remotely exploitable by itself and is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, so urgency is highest for multi-user Linux systems, shared workstations, kiosks, lab systems, and servers where untrusted users have local shell or console access.

How an attack unfolds

An attacker first obtains local access to a Linux system with permission to interact with a virtual terminal and issue console font operations. They attempt to place the system under memory pressure or otherwise cause vc_resize() to fail during a console font change. During fbcon_do_set_font(), the kernel may temporarily enable high-font handling and mutate the screen buffer. If the later resize step fails, the vulnerable error handler incompletely rolls back state: the font character count is restored, but the high-font mask and screen buffer state are not. The attacker then writes character indexes that are valid only while high-font mode is still considered active. When framebuffer console rendering occurs, fbcon_putcs() uses those oversized indexes against the reverted 256-character font array, reading beyond the expected font memory. Depending on kernel build, console configuration, and what data is adjacent in memory, the attacker may recover kernel memory contents or cause instability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fbdev/fbcon fix adding proper rollback of the high-font mask and screen buffer in the fbcon_do_set_font() error path. If distribution packages are used, apply the relevant vendor kernel security update rather than relying only on upstream version numbers. No exact fixed package versions were provided in the input, so confirm remediation through the operating system vendor advisory, kernel changelog, or source patch reference for the fbcon_do_set_font() rollback fix. Where immediate patching is not possible, reduce exposure by limiting local shell access to trusted users, disabling or restricting framebuffer console/virtual terminal font manipulation where operationally feasible, removing unnecessary console font utilities from untrusted environments, and applying standard hardening controls that reduce the usefulness of kernel memory disclosure, such as kernel address-space layout randomization and strict local privilege controls.

How to confirm the fix worked

Confirm that the installed kernel package contains the fbdev/fbcon patch for fbcon_do_set_font() that restores hi_font state on the err_out path. Validate through vendor package metadata, distribution security advisories, kernel changelogs, or source inspection showing rollback of vc_hi_font_mask and related screen buffer state after failure. Inventory systems for framebuffer console and virtual terminal usage, especially systems with /dev/tty*, /dev/console, or framebuffer console enabled. Where safe in a test environment, regression testing should verify that failed console font changes do not leave high-font state enabled or permit rendering with inconsistent font character counts. Do not attempt exploit-style validation on production systems because the trigger depends on kernel memory pressure and may cause instability.

Typical attack path

1. Gain local authenticated access to a Linux host with access to virtual terminal/framebuffer console font interfaces.
2. Interact with the console font-setting path, typically through virtual terminal font ioctls or console font utilities.
3. Induce or wait for a failure in the resize/allocation path during fbcon_do_set_font(), for example under heavy memory pressure.
4. Leave the virtual terminal in a desynchronized high-font state where vc_hi_font_mask remains enabled while the font array has reverted to 256 characters.
5. Submit character indexes above 255 to the virtual terminal screen buffer.
6. Trigger framebuffer console rendering so fbcon_putcs() reads out of bounds from kernel memory.
7. Use leaked kernel memory to disclose sensitive data, defeat exploit mitigations, or support a follow-on local privilege-escalation chain.

How to detect it

Post-exploitation detection is difficult because successful exploitation may not create a dedicated log entry and the leaked data may only be visible to the local process interacting with the console. Focus on correlated signals: audit logs for unusual access to virtual terminals and console devices, command history or process telemetry showing console font utilities, kernel logs showing fbcon/fbdev/VT warnings or crashes, and resource telemetry indicating deliberate memory pressure near the time of console font operations. Relevant log sources include auditd, eBPF/EDR process telemetry, shell history where available, syslog/journald kernel messages, crash dumps, and package/kernel inventory. Look for non-administrative users running console font tools such as setfont, consolechars, loadunimap, or custom binaries issuing VT font ioctls against /dev/tty*, /dev/console, or /dev/fb*. Also review for follow-on behavior consistent with use of a kernel memory disclosure, such as probing kernel addresses, loading suspicious local exploit tooling, unexpected privilege changes, or kernel oops messages mentioning fbcon_do_set_font(), set_vc_hi_font(), vc_resize(), or fbcon_putcs().

• fbcon_do_set_font
• set_vc_hi_font
• vc_resize
• fbcon_putcs
• /dev/tty0
• /dev/tty1
• /dev/console
• /dev/fb0
• setfont
• consolechars
• loadunimap
• KD_FONT_OP_SET
• PIO_FONT
• PIO_FONTX
• fbcon
• fbdev
• vc_hi_font_mask

What your security team should do

• Prioritize patching multi-user Linux systems, shared workstations, kiosks, and systems where untrusted users have local accounts or console access.
• Track the relevant Linux distribution advisories and update to the vendor-fixed kernel as soon as available; reboot systems so the fixed kernel is actually running.
• Reduce local attack surface by limiting membership and permissions that allow console or virtual terminal font changes.
• Review whether framebuffer console support is required on servers; disable unnecessary console/framebuffer functionality where compatible with operations.
• Monitor for unusual local console font operations, virtual terminal ioctls, and memory-pressure activity by non-administrative users.
• Investigate kernel warnings, oopses, or crashes involving fbcon, fbdev, virtual terminal, console font handling, or out-of-bounds memory access.
• Because this can leak kernel memory, treat suspected exploitation as a possible precursor to local privilege escalation and expand investigation to subsequent suspicious root-level activity.