On June 2024, a security issue tracked as CVE-2024-50134 was announced and quickly patched in the Linux kernel’s VirtualBox GPU driver (vboxvideo). This bug is tied to how the driver handled mouse pointer shape data with a so-called “fake VLA” (Variable Length Array) at the end of a structure. In simple terms: The way it was writing memory could have caused writing past the intended boundary, which modern kernels now warn about. Here’s a breakdown of what happened, why it matters, and a glance at the technical details including actual code snippets and exploitation context.

The Background

In kernel code, especially driver code, it's common to pass data structures that include "extra space" at the end. A quick hack to do this is to define a u32 data[1]; at the end of the struct. The code then allocates extra space and pretends data[1] is larger. Modern compilers and memory sanitizers frown upon this, since it can lead to pointer aliasing issues and boundary errors.

In drivers/gpu/drm/vboxvideo/hgsmi_base.c, the struct vbva_mouse_pointer_shape ended with a fake array like this, and memcpy was called with a big size, far beyond the size of the struct. This is what caused the kernel warning:

memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)

Best case: A kernel warning and the driver still works.

- Worst case: In a different world (especially older kernels or different compilers), this kind of coding can potentially lead to buffer overflows, information leaks, or even code execution with kernel privileges.

Here’s a simplified example similar to the problematic part

struct vbva_mouse_pointer_shape {
    ... // other fields
    u32 data[1]; // fake VLA, really should be variable size
};

...

size_t size = calculate_size_needed();
struct vbva_mouse_pointer_shape *p = kmalloc(size, GFP_KERNEL);
memcpy(p->data, from_user_buffer, big_data_size); // size can be much > 4 bytes!

The problem: data is only sized for 1 u32, but you are copying way more data!

The patch swapped the fake array for the real C99 VLA notation

// C99 flexible array member
struct vbva_mouse_pointer_shape {
    ... // other fields
    u32 data[]; // real VLA: no number between []
};

Now the kernel (and sanitizers) recognize the intent. So long as the allocation matches the true needed size, memcpy is happy. Here’s the new line:

size_t size = calculate_size_needed();
struct vbva_mouse_pointer_shape *p = kmalloc(size, GFP_KERNEL);
memcpy(p->data, from_user_buffer, big_data_size); // Now it's officially legit.

Is this exploitable?

For the strictest definition of vulnerability: CVE-2024-50134 is a memory safety issue, not RCE (Remote Code Execution), on its own. Because the code carefully calculates allocation size, there is no direct overflow. But code that pokes at memory boundaries in this way makes auditing hard and has a dark history:

Past bugs of this pattern have been used for info leaks or to “land” later bugs.

- Syzkaller and Kernel Sanitizer tools highlight this as serious: it’s very close to "out-of-bounds write," the root of countless security holes.
- An attacker who can trigger this code path with malformed data in guest VM *might* combine it with other issues to escalate privileges in the guest.

As-is, it triggers a line in dmesg like

  WARNING: CPU:  PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+x192/x1c [vboxvideo]

Upstream Patch:

drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA

Linux Kernel CVE Record:

CVE-2024-50134 at cve.org
- Syzkaller bug report / warning:
Kernel Bugzilla Reference *(search for vboxvideo and CVE id)*

Documentation on flexible array members:

Linux Kernel Doc: The right way to do variable-length structures

Takeaways

- If you run VirtualBox guest kernels, especially with shared clipboard/display features, update your kernel or guest additions.

Code quality matters in device drivers, especially in memory allocation boundaries.

- Modern tools are your friend: compiler warnings and code sanitizers catch what the old C codebase let slide.

Final Thoughts

CVE-2024-50134 itself won't bring down the Internet, but it’s a classic case of cleaning up old kernel code to prevent future, potentially much worse bugs. The line between a warning and a security exploit is often very thin. Keeping kernel code modern and standards-compliant makes Linux more secure for everyone — whether you're running a server, a desktop VM, or cloud containers.

Timeline

Published on: 11/05/2024 18:15:16 UTC
Last modified on: 11/08/2024 16:15:47 UTC