Re: Possible bug in drivers/tty/vt/vt.c

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jun 23, 2020 at 05:27:33AM -0400, Anthony Canino wrote:
> Hi all,
> 
> I hope this is the right place to ask about a potential bug in the TTY
> that I may have found in the TTY layer in the linux kernel. I have
> failed a bug report
> (https://bugzilla.kernel.org/show_bug.cgi?id=208293) but wanted to
> email the list for the TTY layer directly. In summary, in the con_init
> function of drivers/tty/vt/vt.c, I think this code is possibly buggy
> is kzalloc fails to allocate:
> 
>   3391   for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
>   3392     vc_cons[currcons].d = vc = kzalloc(sizeof(struct vc_data),
> GFP_NOWAIT);
>   3393     INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
>   3394     tty_port_init(&vc->port);
>   3395     visual_init(vc, currcons, 1);
>   3396     vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
>   3397     vc_init(vc, vc->vc_rows, vc->vc_cols,
>   3398       currcons || !vc->vc_sw->con_save_screen);
>   3399   }
>   3400   currcons = fg_console = 0;
>   3401   master_display_fg = vc = vc_cons[currcons].d;
>   3402   set_origin(vc);
> 
> If kzalloc returns null on 3396, I think during set_origin(vc) it is
> possible vc_screenbuf will be dereferenced. I'd be happy to discuss
> further if needed.

Yes, horrible and bad things will happen if kzalloc fails at that point
in time.

Luckily, it is impossible for that to happen, so we really do not need
to worry about it at all.  This comes up every other year or so, and the
gyrations that people have gone through to try to fix this up, for
something that is impossible to ever hit, always end up breaking the
codebase or doing other horrible things.

In short, don't worry about it, unless you can show me how that can ever
happen in a normal (i.e. not instrumented) system?

thanks,

greg k-h