Re: [PATCH] vt: keyboard: add NULL check for vc_cons[fg_console].d in kbd_keycode and kbd_rawcode

[Greg Kroah-Hartman]

On Fri, Mar 13, 2026 at 02:54:01PM -0400, Daniel Hodges wrote:
> On Thu, Mar 12, 2026 at 03:22:09PM +0100, Greg Kroah-Hartman wrote:
> > On Sat, Feb 07, 2026 at 07:31:12PM -0500, Daniel Hodges wrote:
> > > kbd_keycode() and kbd_rawcode() dereference vc_cons[fg_console].d
> > > without checking if it is NULL. The foreground console should normally
> > > always be allocated, but there could be a time during console setup or
> > > teardown where this pointer could be NULL, leading to a general
> > > protection fault.
> > > 
> > > Syzkaller triggers this by injecting USB HID input events that reach
> > > kbd_event() while the console state may not be fully consistent. The crash
> > > manifests as a null-ptr-deref in __queue_work when put_queue() or
> > > puts_queue() calls tty_flip_buffer_push() on the uninitialized vc port.
> > > 
> > > Add a NULL check for vc at the start of both kbd_rawcode() and
> > > kbd_keycode() to bail out early if the foreground console is not allocated.
> > > 
> > > Reported-by: syzbot+c3693b491545af43db87@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Closes: https://syzkaller.appspot.com/bug?extid=c3693b491545af43db87
> > > Reported-by: syzbot+03f79366754268a0f20c@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Closes: https://syzkaller.appspot.com/bug?extid=03f79366754268a0f20c
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Signed-off-by: Daniel Hodges <git@xxxxxxxxxxxxxxxx>
> > > ---
> > >  drivers/tty/vt/keyboard.c | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> > > index a2116e135a82..975830013d24 100644
> > > --- a/drivers/tty/vt/keyboard.c
> > > +++ b/drivers/tty/vt/keyboard.c
> > > @@ -1389,6 +1389,9 @@ static void kbd_rawcode(unsigned char data)
> > >  {
> > >  	struct vc_data *vc = vc_cons[fg_console].d;
> > >  
> > > +	if (!vc)
> > > +		return;
> > > +
> > 
> > What prevents vc from being NULL right after checking this?
> 
> Yeah, your right about that. I spent a bit of time to make a reproducer
> using a kernel module and I think if RCU is used on vc_cons[].d it
> should then be properly protected. Let me know if that sounds like a
> reasonable approach and I can send a v2.

Maybe?  But can this really ever be hit on a non-syzkaller workload?

thanks,

greg k-h