Cloudanix VulnDB

CVE-2026-98840

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug in console handling can let attackers crash systems or potentially run code by using memory that has already been freed.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free due to stale non-NULL vc_data pointer passed to vcs_scr_updated() after concurrent free via vc_port_destruct, resulting in vcs_notifier() reading vc_num from freed slab memory.

Why it matters to the business

Kernel crashes or potential privilege escalation on Linux systems, increasing downtime and security risk for servers and devices relying on virtual consoles.

How an attack unfolds

Attacker opens a virtual console and triggers concurrent VT_DISALLOCATE ioctl during an unlocked copy_from_user window in vcs_write(), freeing the vc structure; the post-loop vcs_scr_updated() then dereferences the stale pointer through the notifier chain.

How to fix it

Update the Linux kernel to a version containing the fix that moves the vc reload immediately after console_lock() and before the if (ret) check in vcs_write().

How to confirm the fix worked

Inspect vcs_write() source to confirm vc reload precedes the ret check, recompile, and verify absence of KASAN slab-use-after-free reports during concurrent vcs operations.

Typical attack path

  1. Open virtual console device
  2. Issue concurrent VT_DISALLOCATE while vcs_write() is active
  3. Trigger copy failure path that skips vc reload
  4. Reach vcs_scr_updated() with freed vc
  5. vcs_notifier() reads from freed memory

How to detect it

Search kernel logs and crash reports for KASAN slab-use-after-free messages referencing vcs_notifier or vcs_write, and trace call stacks showing vc_allocate to vt_ioctl frees.

  • BUG: KASAN: slab-use-after-free in vcs_notifier+0x7c/0xd0
  • vcs_scr_updated+0x77/0xa0
  • vcs_write+0x71b/0x7e0
  • Read of size 2 at addr.*vc_num
  • Freed by task: kfree <- vt_ioctl (VT_DISALLOCATE

What your security team should do

  • Prioritize kernel updates across all affected distributions
  • Restrict unprivileged access to /dev/vcs* devices where feasible
  • Enable KASAN or similar memory debugging in test environments
  • Monitor upstream stable branches for backports

The record

In the Linux kernel, the following vulnerability has been resolved: vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF The reload of 'vc' added by commit 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF") sits after the 'if (ret)' block, so the copy-failure break path exits the loop without reloading vc. If the vc was kfree()'d via vc_port_destruct during the unlocked copy_from_user() window, the post-loop 'if (written && vc) vcs_scr_updated(vc)' is reached with a stale non-NULL vc. The '&& vc' guard from commit a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") only handles the NULL case, not this stale-non-NULL case; vcs_notifier() then reads param->vc->vc_num from freed memory: BUG: KASAN: slab-use-after-free in vcs_notifier+0x7c/0xd0 Read of size 2 at addr ffff888007149190 Call Trace: vcs_notifier+0x7c/0xd0 atomic_notifier_call_chain+0x70/0xa0 vcs_scr_updated+0x77/0xa0 vcs_write+0x71b/0x7e0 Allocated by task: vc_allocate -> con_install -> tty_open Freed by task: kfree <- vt_ioctl (VT_DISALLOCATE -> vc_port_destruct) Move the reload to immediately after console_lock(), before 'if (ret)', so every break path below passes a fresh vc to the post-loop vcs_scr_updated().

Affected packages

Ecosystem Package Introduced Fixed