CVE-2026-63926

What it actually does

This is a Linux kernel memory-corruption flaw in the BPF sockmap/sk_msg path. When bpf_msg_push_data() inserts data into the middle of a non-first scatter-gather entry, it advances the right-side fragment offset using a message-global offset instead of the fragment-local delta. That can leave the scatterlist layout inconsistent and cause incorrect kernel memory references. Depending on kernel configuration and exploitability on a given build, the result may be kernel crash, memory corruption, information disclosure, or local privilege escalation. Practical exposure is highest where unprivileged eBPF is enabled or where users, containers, or services can obtain BPF-related capabilities such as CAP_BPF or CAP_SYS_ADMIN.

Why it matters to the business

A successful exploit could let a local attacker or compromised workload destabilize or take over a Linux host, potentially causing service outages, data exposure, or container/host boundary compromise. Although the current EPSS is low, the issue has high technical severity because it affects kernel memory safety and does not require user interaction. It is not currently listed in CISA KEV and no ransomware association is reported, so prioritization should be driven by kernel exposure, multi-tenant risk, container density, and whether unprivileged BPF is enabled.

How an attack unfolds

An attacker first obtains the ability to run code locally on a vulnerable Linux system, either as a regular user if unprivileged BPF is permitted or through a compromised process/container with sufficient BPF privileges. The attacker loads or triggers a BPF sockmap/sk_msg program that uses bpf_msg_push_data() against socket data arranged across multiple scatter-gather entries. By inserting data into the middle of a non-first entry, the vulnerable kernel miscalculates the tail fragment offset, corrupting the internal message layout. The attacker then attempts to shape the corrupted state so the kernel reads, writes, or frees memory incorrectly. In a basic case this may crash the host; in a more advanced case it may be used to leak kernel memory or gain elevated privileges. There is no public exploit maturity reported in the input, but memory-corruption flaws in privileged kernel paths should be treated as high-value targets once technical details are available.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix for bpf_msg_push_data() tail-fragment offset handling in the BPF sockmap code. Because no exact fixed package versions were provided, use vendor advisories and package changelogs to identify the first fixed kernel for each supported distribution, then reboot into the updated kernel. As interim mitigations, disable unprivileged BPF where operationally possible using kernel.unprivileged_bpf_disabled=1, restrict CAP_BPF, CAP_SYS_ADMIN, and CAP_NET_ADMIN from users and containers, avoid privileged containers, enforce seccomp/AppArmor/SELinux profiles that block unnecessary bpf() syscall use, and enable kernel lockdown or BPF JIT hardening where compatible. Mitigations reduce attack surface but should not be treated as a substitute for applying the kernel fix.

How to confirm the fix worked

Confirm the active running kernel, not only the installed package, is a vendor-fixed build by checking uname -r, package manager status, reboot history, and vendor advisory mapping. Validate that the kernel changelog or source package includes the BPF sockmap fix for bpf_msg_push_data() using the fragment-local delta for the right fragment offset. Confirm unprivileged BPF posture with sysctl kernel.unprivileged_bpf_disabled and review whether BPF capabilities are granted to containers, services, or user sessions. Use bpftool to inventory loaded BPF programs and maps and verify that unexpected SOCKMAP, SOCKHASH, or SK_MSG programs are not present. If mitigations are used, test that non-privileged users cannot successfully invoke the bpf() syscall to load BPF programs.

Typical attack path

1. Gain local code execution on a Linux host, container, or service account.
2. Determine whether BPF use is possible, such as via unprivileged BPF or capabilities like CAP_BPF, CAP_NET_ADMIN, or CAP_SYS_ADMIN.
3. Create or load BPF sockmap/sk_msg functionality involving SOCKMAP or SOCKHASH maps.
4. Trigger bpf_msg_push_data() with crafted socket message data that spans multiple scatter-gather entries.
5. Force insertion into the middle of a non-first scatterlist entry so the kernel computes an incorrect tail-fragment offset.
6. Leverage the resulting memory corruption to crash the kernel, disclose memory, or attempt privilege escalation.
7. If privilege escalation succeeds, establish persistence, tamper with logs, or move laterally from the compromised host.

How to detect it

Reliable post-exploitation detection is difficult because successful kernel memory-corruption exploitation may leave few application-level artifacts. Focus on kernel logs, audit telemetry, and BPF inventory. Review dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, and kernel panic/oops records for faults involving BPF, sockmap, sk_msg, scatterlist handling, or bpf_msg_push_data(). Search auditd or eBPF-based telemetry for bpf() syscall activity by unexpected users or processes, especially creation of BPF_PROG_TYPE_SK_MSG programs and BPF_MAP_TYPE_SOCKMAP or BPF_MAP_TYPE_SOCKHASH maps. Investigate executions of bpftool, custom loaders, or suspicious processes with CAP_BPF, CAP_NET_ADMIN, or CAP_SYS_ADMIN. On systems with KASAN or other kernel sanitizers, prioritize reports of out-of-bounds, use-after-free, or invalid-access events in net/core/skmsg.c or BPF sockmap code. Use bpftool prog show, bpftool map show, and bpftool net to look for unexpected loaded programs, maps, or attachments. Correlate suspicious BPF activity with kernel crashes, service restarts, privilege changes, new root-owned files, new setuid binaries, or log tampering around the same time window.

• bpf_msg_push_data
• sk_msg
• sockmap
• SOCKMAP
• SOCKHASH
• BPF_PROG_TYPE_SK_MSG
• BPF_MAP_TYPE_SOCKMAP
• BPF_MAP_TYPE_SOCKHASH
• bpftool prog
• bpftool map
• bpftool net
• sys_enter_bpf
• bpf(BPF_PROG_LOAD
• BPF_PROG_LOAD
• kernel.unprivileged_bpf_disabled
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• net/core/skmsg.c

What your security team should do

• Prioritize patching internet-facing, multi-tenant, container-dense, build, CI/CD, developer, and shared Linux systems where local code execution by less-trusted users is plausible.
• Disable unprivileged BPF across the fleet unless there is a documented business requirement.
• Remove BPF-related Linux capabilities from containers and services by default; avoid privileged containers and broad CAP_SYS_ADMIN grants.
• Inventory loaded BPF programs and maps on high-value hosts and investigate unexpected sockmap, sockhash, or sk_msg usage.
• Add detections for suspicious bpf() syscall activity, bpftool usage, kernel oops/panic events, and KASAN reports referencing BPF sockmap or bpf_msg_push_data().
• Monitor vendor advisories for exact fixed kernel package versions and ensure systems are rebooted into the patched kernel after installation.
• Treat unexplained kernel crashes on systems permitting BPF as potentially security-relevant until investigated.