Bug 208293 - Possible null dereference bug in tty/vt/vt.c
Summary: Possible null dereference bug in tty/vt/vt.c
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 low
Assignee: drivers_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-22 20:49 UTC by Anthony Canino
Modified: 2020-06-22 20:49 UTC (History)
0 users

See Also:
Kernel Version: Linux 5.7-rc5
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Anthony Canino 2020-06-22 20:49:18 UTC
Hi, I am part of a group developing a static analysis tool and we are running it on the latest linux kernel (5.7) to search for potential bugs. Our analysis has found a possible an kzalloc whose return is not checked in drivers/tty/vt/vt.c in the con_init function at line 3396. As I understand the following code:

for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
  vc_cons[currcons].d = vc = kzalloc(sizeof(struct vc_data), GFP_NOWAIT);
  INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
  tty_port_init(&vc->port);
  visual_init(vc, currcons, 1);
  vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
  vc_init(vc, vc->vc_rows, vc->vc_cols,
  currcons || !vc->vc_sw->con_save_screen);
}

if kzalloc fails, vc->vc_screenbuf would be set to NULL and possibly dereferenced in the following code, namely when setting the origin (set_origin(vc)). Should there be a check on the kzalloc and an early termination if it fails to allocate?

Note You need to log in before you can comment on or make changes to this bug.