CVE-2026-98840: vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF
In the Linux kernel, the following vulnerability has been resolved:
vcscreen: reload vc pointer before if (ret) in vcswrite() to avoid UAF
The reload of 'vc' added by commit 8fb9ea65c9d1 ("vcscreen: reload load of struct vcdata pointer in vcswrite() 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 vcportdestruct during the unlocked copyfromuser() window, the post-loop 'if (written && vc) vcsscrupdated(vc)' is reached with a stale non-NULL vc. The '&& vc' guard from commit a287620312dc ("vcscreen: fix null-ptr-deref in vcsnotifier() during concurrent vcswrite") only handles the NULL case, not this stale-non-NULL case; vcsnotifier() then reads param->vc->vcnum from freed memory:
BUG: KASAN: slab-use-after-free in vcsnotifier+0x7c/0xd0 Read of size 2 at addr ffff888007149190 Call Trace: vcsnotifier+0x7c/0xd0 atomicnotifiercallchain+0x70/0xa0 vcsscrupdated+0x77/0xa0 vcswrite+0x71b/0x7e0 Allocated by task: vcallocate -> coninstall -> ttyopen Freed by task: kfree <- vtioctl (VTDISALLOCATE -> vcportdestruct)
Move the reload to immediately after consolelock(), before 'if (ret)', so every break path below passes a fresh vc to the post-loop vcsscrupdated().
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
A vcs_write() operation must be in an unlocked copy_from_user() window while another task deallocates the same virtual console through VT_DISALLOCATE, causing vc_port_destruct to free its vc_data. The copy operation must also take the failure path so the stale vc pointer is not reloaded before the post-loop screen-update notification.
What observable impact is described?
The stale non-NULL vc pointer can reach vcs_notifier(), which reads vc_num from freed memory. The reported result is a KASAN-detected slab use-after-free read.
Which kernel functionality is involved in the concurrent free operation?
The freeing path shown is vt_ioctl handling VT_DISALLOCATE, followed by vc_port_destruct and kfree. Systems or workloads that do not use virtual-console deallocation do not match the described concurrent-free path.