In June 2024, the Linux kernel received a crucial patch addressing a vulnerability now tracked as CVE-2024-38662. This issue revolved around how certain types of BPF (Berkeley Packet Filter) programs interacted with specialized networking maps called sockmap and sockhash. If you use BPF for advanced network traffic handling, read on—it’s important to your system’s security posture, and simple to understand if you know the basics of map operations.

What’s the Problem?

Recent fuzzing with 'syzkaller'[1], a powerful Linux kernel bug-discovery tool, exposed a flaw: some BPF programs attached to tracepoints could use bpf_map_delete_elem() to remove entries from sockmap and sockhash types. This violated core kernel locking rules, potentially leading to crashes or other unpredictable behavior. It’s a niche case, but real.

The root cause is straightforward: the kernel didn’t restrict which BPF program types were allowed to delete sockets from these maps. This isn’t supposed to happen. According to the maintainers, it was never their intention to allow deletions except in controlled, well-defined BPF contexts, as updating and deleting have similar, risky effects.

How Did Linux Fix This? (The Patch)

The kernel now checks what type of BPF program is making the deletion call. If a BPF program wasn’t previously allowed to *update* a sockmap/sockhash, it is now also forbidden to delete from it. This defensive measure blocks all attempts to use undesirable program types for deletion, closing the door on accidental or malicious misuse.

Here’s an excerpt from the relevant kernel patch[2]

if ((map_type == BPF_MAP_TYPE_SOCKMAP || map_type == BPF_MAP_TYPE_SOCKHASH) &&
    command == BPF_MAP_DELETE_ELEM) {
    if (!is_allowed_prog_type_for_update(current_prog)) {
        verbose("only specific BPF program types can delete from sockmap/sockhash");
        return -EINVAL;
    }
}

Before, only *updates* (inserts/replaces) were limited—now deletions are, too.

How Would an Exploit Have Worked?

An attacker (or researcher) could write a BPF program, attach it to a tracepoint (intended to watch for various kernel events), and use it to call bpf_map_delete_elem() on a sockmap or sockhash. This action, when performed outside allowed BPF program types, could cause kernel locking violations and trigger kernel bugs. In worst-case scenarios, this can lead to a Denial of Service (DoS) or potentially open up deeper vulnerabilities.

Example exploit scenario

1. Write a BPF program that triggers on a tracepoint and attempts to delete an element from a protected sockmap.

Load and attach the program using the bpf syscall.

3. Trigger the tracepoint during runtime. The delete operation misbehaves and may cause memory corruption or lock mismatches, potentially crashing the kernel.

Here’s a simplified pseudo-code BPF example (won’t work on patched systems)

SEC("tracepoint/syscalls/sys_enter_execve")
int bpf_prog(struct bpf_sock_ops *ctx)
{
    int key = ;
    bpf_map_delete_elem(&sock_map, &key);
    return ;
}

This should not be allowed—but was possible on unpatched kernels! After the patch, the BPF verifier will reject such programs.

How Can You Stay Safe?

- Upgrade your kernel to a version containing this patch (mainline and stable branches as of June 2024).
- Do not load untrusted BPF programs, especially if they deal with sockmap/sockhash.
- Review your program types: Only BPF_PROG_TYPE_SK_MSG and similar allowed types can now update or delete entries from sockmaps/sockhashes.

References and Further Reading

- Kernel commit fixing CVE-2024-38662
- syzkaller bug tracker
- sockmap/sockhash documentation
- Discussion of this bug on the bpf mailing list

Conclusion

CVE-2024-38662 might seem obscure, but it catches a classic “fuzz-finding” bug: when internal restrictions don’t match expectations, security boundaries get fuzzy. If you rely on Linux for network-critical workloads and use BPF maps, make sure you’re patched and enforce strict BPF program policies. Details matter—kernels now echo that in code.


[1] https://github.com/google/syzkaller
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29b19e3b667b73f2b46f3e8bebb91d908c53f52c


*Written exclusively for you, in clear language, by an AI trained on the latest open-source security news.*

Timeline

Published on: 06/21/2024 12:15:11 UTC
Last modified on: 06/24/2024 18:34:17 UTC