CVE-2024-50080 is a recently resolved vulnerability in the Linux kernel's UBLK (Userspace Block Device) subsystem. This bug could let an unprivileged user perform actions on a block device that are potentially unsafe, opening up system integrity and exploit risks. If you're running Linux and using ublk devices, this is one you'll want to know about.

Below, we break down this vulnerability, how it works, with example code, the patch, and what you should do about it.

Affected Versions: Linux kernel with UBLK subsystem prior to the patch (merged mid-June 2024)

Short Description:
The kernel allowed unprivileged devices to use the UBLK_F_USER_COPY flag. This flag lets *userspace* fill a request buffer by calling write() on the device. But for unprivileged devices, this lets a user supply arbitrary data to kernel buffers, breaching a trust boundary.

UBLK Subsystem and UBLK_F_USER_COPY Explained

The UBLK subsystem exposes block devices to user space by presenting a character device node (e.g. /dev/ublkb). User space programs handle read/write requests, which are usually processed in the kernel.

The UBLK_F_USER_COPY flag is important

- When set, userspace processes must supply buffer data for block I/O by writing to the char device via write().
- Intended Use: For privileged processes that carefully coordinate with the kernel, it supports fast zero-copy block I/O.
- Problem: If unprivileged devices are allowed to use UBLK_F_USER_COPY, less trusted user space code gets to control things the kernel shouldn’t trust it with.

Root Cause Analysis

The vulnerability is traced to how the kernel checks (or fails to check) privileges when setting up a ublk device:

The UBLK setup did not restrict the use of UBLK_F_USER_COPY to privileged devices.

- This leads to a scenario where *any* user can open a ublk char device configured this way and supply arbitrary buffer contents via write().

Code Snippet and Patch

Here is the crucial part of the kernel source code before and after the fix.

BEFORE (Vulnerable)

// drivers/block/ublk_drv.c

if (params->flags & UBLK_F_USER_COPY) {
    // ... Allow user copy, regardless of privilege
    dev->user_copy = true;
}

AFTER (Patched)

// drivers/block/ublk_drv.c

if ((params->flags & UBLK_F_USER_COPY) && ublk_is_privileged(params)) {
    // Allow only if device is privileged
    dev->user_copy = true;
} else {
    dev->user_copy = false;
}

Here, ublk_is_privileged(params) is a new privilege check (introduced in the patch) which ensures only trusted/privileged code can enable UBLK_F_USER_COPY.

See the official patch for reference.

How an Attacker Could Abuse CVE-2024-50080

Suppose a Linux system lets untrusted users create or interact with unprivileged ublk devices. Here's a simple exploit outline:

1. Create / Open an unprivileged ublk device (if permitted by policy).

Write malicious data to the device:

Userspace can send crafted I/O buffers using write(), which the kernel would then consume for block operations.

Bypassing kernel-space buffer checking

- Potential *privilege escalation* if further bugs are present or other kernel pieces trust the supplied buffer

Example (simplified)

int fd = open("/dev/ublkb", O_RDWR);
char evil_data[512] = { /* crafted */ };
write(fd, evil_data, sizeof(evil_data));  // Used to fill the kernel buffer!

If the kernel processes this buffer, it trusts unprivileged user's data at a sensitive boundary, which can be leveraged depending on kernel build and other local security measures.

Upgrade your Linux kernel to include the patch above!

- Direct Patch: If you self-compile, pull in the official patch here.

Prevent untrusted users from creating or accessing ublk devices as an added precaution.

No workaround is recommended except disabling ublk devices for unprivileged users or patching up.

References

- CVE-2024-50080 NVD Entry
- Official Linux kernel patch
- LKML Discussion

Conclusion

CVE-2024-50080 is a classic example of why privilege boundaries are important. In this case, the Linux kernel's block device subsystem trusted userspace a bit too much, but the fix is simple: restrict dangerous operations to privileged code.

Always keep your kernel up to date, and be mindful when exposing device nodes such as ublk char devices to userspace—especially in multi-user environments.

Timeline

Published on: 10/29/2024 01:15:05 UTC
Last modified on: 10/30/2024 15:54:17 UTC