From: Liav Mordouch <liavmordouch@gmail.com>
To: stable@vger.kernel.org
Cc: gregkh@linuxfoundation.org, npitre@baylibre.com,
linux-kernel@vger.kernel.org
Subject: [BUG] csi_J oops on VT write after upgrading to 6.19.10 -- NULL pointer dereference in do_con_write path
Date: Fri, 27 Mar 2026 19:00:50 +0300 [thread overview]
Message-ID: <20260327160050.31631-1-liavmordouch@gmail.com> (raw)
After upgrading from 6.19.9 to 6.19.10, I'm getting a kernel oops in csi_J()
every time something writes a CSI J (clear screen) escape sequence to a VT
console. In my case it's greetd/tuigreet running `clear` on tty1 at login,
but the crash is in the kernel VT code itself, not specific to greetd.
The result is a completely black screen with no keyboard input accepted -- can't
switch VTs, can't do anything besides a hard power off. It happens consistently
on 4 out of 5 boots with 6.19.10. The one boot that didn't crash was when I
manually switched to tty2 before tuigreet had a chance to write to tty1.
Reproducer:
1. Boot 6.19.10
2. Have a login manager (or anything, really) send a clear/CSI J sequence to a VT
3. Kernel oops in csi_J, system is bricked until reboot
I bisected across my boot history using journalctl -- 6.19.9 is fine:
Kernel Boots checked csi_J crashes
6.19.8 2 0
6.19.9 24 0
6.19.10 5 4
The 6.19.10 changelog includes a backport of 5eb608319bb5 ("vt: save/restore
unicode screen buffer for alternate screen"), which is a fix for 23743ba64709
("vt: add support for smput/rmput escape codes"). That commit modifies
vc_uni_lines handling and adds vc_saved_uni_lines for alternate screen
save/restore. I suspect the backport doesn't apply cleanly or has a missing
dependency -- the faulting address (0x0000002000000020 in RDI during a rep stosd
in csi_J) looks like a corrupted vc_uni_lines pointer.
6.19.9 does not contain this commit and works perfectly.
System:
Gentoo Linux, AMD Ryzen 5 5600X, AMD RX 7800 XT (amdgpu)
Gigabyte B450M DS3H V2, BIOS F65b
Boot cmdline: BOOT_IMAGE=/boot/kernel-6.19.10-gentoo-dist root=UUID=... ro zswap.enabled=1 zswap.compressor=lz4 amdgpu.ppfeaturemask=0xffffffff
Oops from boot -1 (journalctl -b -1):
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 11 UID: 0 PID: 1037 Comm: greetd Tainted: G S 6.19.10-gentoo-dist #1 PREEMPT(full)
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H V2/B450M DS3H V2, BIOS F65b 09/20/2023
RIP: 0010:csi_J+0x133/0x2d0
Code: a4 01 00 00 b8 20 00 00 00 f3 ab 83 fa 01 74 25 48 c1 e2 03 be 08 00 00 00 48 8b 8b 30 03 00 00 48 8b 3c 31 8b 8b a4 01 00 00 <f3> ab 48 83 c6 08 48 39 d6 75 e4 8b 93 a8 01 00 00 0f af 93 a4 01
RSP: 0018:ffffd34941133988 EFLAGS: 00010283
RAX: 0000000000000020 RBX: ffff8b1fc034b800 RCX: 00000000000000f0
RDX: 0000000000000218 RSI: 00000000000000c8 RDI: 0000002000000020
RBP: 0000000000000007 R08: 00000000ffffffff R09: ffff8b1fc034b800
R10: 0000000000000000 R11: ffff8b1ffc17cf7f R12: 000000000000004a
R13: 000000000000004a R14: ffff8b20133c7407 R15: ffff8b1fc034b800
FS: 00007fac7b0e11c0(0000) GS:ffff8b234ce30000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000002000000020 CR3: 0000000108854000 CR4: 0000000000f50ef0
PKRU: 55555554
Call Trace:
<TASK>
do_con_write+0x34c/0x5b0
con_write+0x16/0x50
process_output_block+0x82/0x1a0
n_tty_write+0x1ae/0x3f0
iterate_tty_write+0x116/0x240
file_tty_write.isra.0+0x86/0xb0
vfs_write+0x25d/0x480
ksys_write+0x73/0xf0
do_syscall_64+0x7e/0x6b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
This then cascades into a second oops during cleanup (NULL pointer deref at
0x2, RIP: 0010:0x2) followed by "Fixing recursive fault but reboot is needed!"
and a "BUG: scheduling while atomic" -- at that point the VT subsystem is
completely dead.
Same crash reproduced on a separate boot (boot -3, different PID):
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 11 UID: 0 PID: 2485 Comm: greetd Tainted: G S 6.19.10-gentoo-dist #1 PREEMPT(full)
RIP: 0010:csi_J+0x133/0x2d0
RDI: 0000002000000020 (same bogus pointer)
Call Trace:
do_con_write+0x34c/0x5b0
con_write+0x16/0x50
process_output_block+0x82/0x1a0
(same stack)
Workaround: boot 6.19.9 instead.
Note: writing of this report was assisted by AI for grammar and flow.
next reply other threads:[~2026-03-27 16:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 16:00 Liav Mordouch [this message]
2026-03-27 16:55 ` [PATCH] vt: discard stale unicode buffer on alt screen exit after resize Liav Mordouch
2026-03-27 17:02 ` [PATCH v2] " Liav Mordouch
2026-03-27 17:26 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260327160050.31631-1-liavmordouch@gmail.com \
--to=liavmordouch@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npitre@baylibre.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.