CVE-2025-68378: Linux BPF Stackmap Overflow Fixed and Mitigations

A newly recorded Linux kernel vulnerability, tracked as CVE-2025-68378, fixes a dangerous boundary-check omission in the BPF stackmap handling that could produce a KASAN-detected slab out‑of‑bounds write when copying stack trace entries into a stackmap bucket. The flaw was reported by the Syzkaller fuzzing system, patched upstream by the kernel BPF maintainers, and published in public vulnerability databases; affected hosts should treat this as an availability- and integrity-risk bug that requires prompt kernel updates or mitigations where patching is delayed.

Background / Overview​

The Linux kernel’s eBPF subsystem exposes powerful runtime programmability for networking, observability, and security. To support stack-trace based instrumentation, BPF provides specialized map types (stackmaps) and helpers such as __bpf_get_stackid to capture and deduplicate kernel stack traces. These helpers copy stack-frame pointers into a per-bucket data array inside a stackmap, and correctness of bounds checks is critical: an oversize trace or an incorrect check can allow writes past the end of the destination bucket and corrupt kernel memory.
Syzkaller — the automated kernel fuzzer — found a KASAN (KernelAddressSANitizer) slab out‑of‑bounds write triggered by bpf_get_stackid when perf trace data contained more stack entries than the stackmap bucket could hold. The upstream kernel tree received a targeted patch that adjusts the overflow check in bpf_get_stackid, preventing the out‑of‑bounds copy and eliminating the KASAN fault. The NVD entry and multiple vulnerability mirrors document this fix under CVE-2025-68378.

---

Why this matters: stackmap semantics and failure modes​

• Stackmaps store compacted stack trace entries per bucket. A stackmap bucket has a fixed-size data array sized according to map configuration.
• __bpf_get_stackid performs the capture and copies entries from the perf trace into the bucket’s array. If the trace contains more entries than the bucket can hold, and the code computes or checks sizes incorrectly, the copy can overrun the bucket memory.
• The observable failure mode in this case was a KASAN slab-out-of-bounds write — a clear memory corruption symptom that can crash kernels, corrupt allocator structures, or create exploitable primitives depending on surrounding conditions. Syzkaller’s reproducer surfaced the issue reliably in test environments and exposed the code path to maintainers.

This is an availability-and-integrity problem: the immediate public evidence is a memory-safety write and kernel oops/crash, not a guaranteed remote code-execution (RCE) vector. That said, kernel memory-corruption bugs are highly prized in exploit development because they can sometimes be turned into privilege-escalation or RCE primitives when combined with other conditions — or simply weaponized as reliable DoS against multi-tenant infrastructure. Community write-ups of related BPF fixes emphasize these two concerns: fix promptly, and harden BPF access policies while patches are staged.

---

Technical root cause — what went wrong​

At a high level, the bug is a classic bounds/overflow-check mistake in a kernel copy loop:

• The code path reads a perf stack trace (a sequence of instruction or return addresses).
• It computes how many entries can be copied into the destination bucket’s data array (bucket capacity).
• The check used to decide whether it is safe to copy was insufficient: when the perf trace contains more entries than the destination can hold, the code could still attempt to copy beyond the bucket boundary, producing an 8‑byte write outside the slab — observed as a KASAN slab-out-of-bounds report.

Syzkaller’s KASAN output and stack traces posted to kernel mailing lists show the reported faulting call site inside __bpf_get_stackid and indicate a write beyond the intended bucket array offset. The maintainers responded with a compact patch that tightens the overflow check and ensures the copied count never exceeds the bucket capacity. The patch author noted the issue and included a syzbot report tag in commit metadata. Practical takeaway: the fix is a small logic correction — ensure arithmetic and comparisons that compute copy lengths are correct and performed in a safe integer width, and clamp values before performing memory writes.

---

Reproducer and community testing​

• Syzkaller produced an automated reproducer (publicly linked in the kernel mailing list threads) that reliably triggered the KASAN slab violation in the pre-patch kernel. That reproducer was used by maintainers and third‑party testers to validate candidate fixes. The syzbot report includes kernel console logs and minimal C reproducer code showing the failing trace path.
• Multiple test cycles followed: syzbot attempted to apply an initial patch and reported follow-up failures and later success after a revised patch iteration. The authoritative patch message (Arnaud Lecomte’s [PATCH v2 2/2]) documents the corrected overflow check and links the syzbot report as the reported-by tag.

Using the reproducible syzbot artifacts is the fastest route for vendors and maintainers to validate that their kernel backport eliminates the KASAN trace.

---

Affected systems and realistic exposure​

• Affected code: the kernel BPF stackmap implementation (kernel/bpf/stackmap.c) prior to the stable backport that contains the fix.
• Attack vector: local program loading or privileged tooling that interacts with BPF stackmaps and perf traces. To trigger the fault, an attacker or test harness must be able to invoke the affected helper with a perf trace containing more entries than the stackmap bucket can accept.
• Privilege model: whether an attacker can exploit the bug depends on host policy — many distributions and hardened systems restrict unprivileged BPF program loads (via kernel.unprivileged_bpf_disabled and capability gating like CAP_BPF or CAP_SYS_ADMIN). Systems that allow unprivileged BPF loads, or have poorly restricted observability/telemetry agents that accept arbitrary BPF programs, are more exposed.

Exploitability assessment (practical):

• Immediate, confirmed impact: KASAN-detected slab out-of-bounds write and potential kernel oops/panic — an availability risk.
• Remote exploitation: unlikely by default, because the vector is local and requires BPF program loading or privileged interaction with tracing APIs.
• Chaining risk: memory corruption at kernel level is high-value for attackers who already have a foothold; therefore treat the bug seriously even if no public RCE PoC exists at disclosure. Community advisories on BPF fixes emphasize this conservative view.

---

Patch, timeline and public records​

• Patch timeline: the syzbot report appeared in July 2025 and follow-up patch discussion occurred in the kernel lists in August 2025. The upstream patch was committed into the kernel trees and later included in stable backports; public CVE records were created and published in December 2025. The NVD published the CVE entry (CVE-2025-68378) on December 24, 2025.
• Upstream references: the vulnerability databases and aggregator pages list the upstream kernel commit(s) that implement the fix and often link to the stable kernel git commits. Some mirrors and trackers include multiple stable-tree commits for various branches that carry the repair. If a vendor lists a fixed kernel package, it should map to one of the upstream commits referenced in those advisories.

Caveat: vendor advisories vary in wording and in how they map upstream commits into packaged kernel versions. One example — a vendor security page URL provided by a user — returned a “page not found” at the time it was checked; when vendor pages are missing or return 404, rely on upstream git commit logs and well-known CVE mirrors (NVD, OSV) for canonical technical details until the vendor publishes an official advisory. Flag unverifiable vendor claims accordingly.

---

Mitigation and remediation guidance​

The definitive remediation is to install vendor-provided kernel updates (or rebuild and deploy kernels that include the upstream fix). Kernel fixes require reboot (or kexec) to take effect.
Short-term mitigations and operational measures (if patching is delayed):

• Harden BPF loading policies:
• Set kernel.unprivileged_bpf_disabled = 1 on shared or multi‑tenant hosts to prevent untrusted users from using the bpf syscall.
• Restrict CAP_BPF and CAP_SYS_ADMIN so only trusted service accounts and administrators hold these capabilities.
• Audit and control eBPF toolchains and agents:
• Review which observability, tracing or dataplane agents (XDP, Cilium, Falco, etc. can load BPF programs; temporarily suspend non-critical deployments that accept untrusted program input.
• Monitor kernel logs and alerts:
• Alert on KASAN reports, kernel oops traces, or messages that point to __bpf_get_stackid, stackmap, or slab out-of-bounds writes. The syzbot output and mailing-list traces show representative dmesg output to match when hunting for occurrences.
• Isolate risky workloads:
• Move developer or research workloads that require unprivileged BPF to isolated VMs to reduce host-level exposure.
• Vendor and distribution tracking:
• Track your distribution’s advisories and package CVE mappings. Use your distribution’s security tracker (Debian/Ubuntu/Red Hat/SUSE/Amazon Linux etc. and confirm the kernel package changelog references the upstream fix commit or the CVE.

Short-term checklist (numbered rollout):

• Inventory: Identify hosts running kernels that predate the fix and that permit BPF program loads. (uname -r; check /boot/config-$(uname -r) or /proc/config.gz; check /proc/sys/kernel/unprivileged_bpf_disabled).
• Prioritise: Put multi‑tenant hosts, CI runners, hypervisors and container hosts that accept untrusted workloads at the top of the list.
• Acquire patches: Obtain vendor kernel packages that list CVE-2025-68378 or the upstream commit in their changelog.
• Pilot: Boot representative test hosts into the patched kernel; run BPF/eBPF workloads and the selftests to verify no regressions.
• Deploy: Stage the update (pilot → broader ring → production). Schedule reboots and maintain rollback plans.
• Validate: After patching, verify the absence of KASAN slab oops, and re-run the testing reproducer where safe.

Community guidance for testing remediation emphasizes running the syzbot reproducer only in controlled test environments — never on production hosts — and collecting vmcore/crash dumps for vendor triage if you see related faults.

---

Detection, telemetry and hunting tips​

Look for these signals when triaging or hunting for evidence of the bug:

• Kernel logs: KASAN slab-out-of-bounds reports that reference __bpf_get_stackid, followed by call traces into kernel/bpf/stackmap.c. These are the exact symptoms reported by syzbot and the patch authors.
• Reproducer correlation: If you’ve run or detected local test harness activity that generates perf trace workloads or BPF loads, correlate kernel logs with bpftool prog show and map show output. Search system telemetry for messages generated near the same timestamps.
• Crash artifacts: Collect vmcore (crash dumps), dmesg logs and the specific syzbot reproducer output if you can reproduce the issue in a lab; these artifacts accelerate vendor triage.

Suggested queries and commands for triage (examples):

• journalctl -k | egrep -i '__bpf_get_stackid|stackmap|KASAN'
• bpftool prog show; bpftool map show
• Verify kernel config exposure: grep -i unprivileged_bpf_disabled /proc/sys/kernel

These diagnostics align with the public reproducer and mailing-list traces that drove the upstream fix.

---

Vendor mapping and the Microsoft link note​

Multiple public vulnerability trackers (NVD, OSV, cvedetails, cvefeed, OpenCVE) list CVE-2025-68378 and point to upstream kernel commits as the fix. These mirrors aggregate the CVE record and the corresponding stable-tree commits. Cross‑referencing these independent sources confirms the same technical summary: a stackmap overflow check needed tightening in __bpf_get_stackid, Syzkaller reported a KASAN slab out‑of‑bounds write, and upstream patches address the issue. A note about the Microsoft Security Response Center (MSRC) page the user attempted to open: the provided MSRC URL returned a “page not found / not available” response at the time of verification. That means Microsoft either has not published a mapping for this specific CVE on that page, has removed or restructured the record, or the URL is incorrect. Because vendor attestation pages are sometimes updated asynchronously, rely on upstream commit evidence and standard CVE mirrors for technical validation until a vendor publishes an explicit product-specific advisory. Flag that vendor-page absence as an unverifiable vendor attestation rather than evidence that Microsoft products are unaffected.

---

Practical recommendations for administrators and developers​

• Apply vendor-supplied kernel patches that include the upstream fix for CVE-2025-68378, then reboot into the patched kernel.
• Temporarily restrict unprivileged BPF loads with sysctl kernel.unprivileged_bpf_disabled=1 where operationally acceptable.
• Audit which services or agents have CAP_BPF/CAP_SYS_ADMIN and reduce grants to the minimum set required.
• Isolate BPF development/test workloads into dedicated VMs to avoid exposing production hosts.
• Prioritize patching hosts that accept untrusted workloads (multi-tenant hypervisors, CI runners, shared developer servers) and hosts that run eBPF-heavy tooling.
• Validate remediation by re-running representative BPF selftests and monitoring for the absence of KASAN slab reports referencing __bpf_get_stackid.

For teams maintaining custom kernels or appliance images: backport the upstream commit carefully and test. The upstream repair is intentionally small and targeted; it can normally be backported without large changes, but any backport must be validated with BPF workloads and the original reproducer in a lab environment.

---

Strengths of the upstream response — and residual risks​

Strengths:

• The upstream fix is surgical and limited in scope — tightening the overflow check rather than altering stackmap semantics — which reduces regression risk and simplifies backporting.
• The bug was caught by Syzkaller and triaged through standard kernel channels with a clear reproducer, which speeds validation and vendor adoption.

Residual risks:

• Long‑tail devices and vendor kernels (embedded appliances, vendor Android kernels, custom appliance images) often lag upstream and may remain vulnerable for months. Operators of such deployments must actively track vendor advisories.
• Even after a patch, hybrid deployments and mixed kernel-version fleets require inventory and staged rollouts to avoid windows of exposure.
• Memory-corruption bugs in kernels are high-value to attackers who already have local footholds; assume that an attacker who can run code locally may attempt to build an exploit chain. Harden policies and patch quickly.

Community writeups about prior BPF vulnerabilities show a consistent pattern: small kernel fixes close local memory- or bounds-check bugs, but the operational playbook must include policy hardening and thorough patch rollouts to reduce overall risk.

---

Quick incident playbook (for a suspected hit)​

• Isolate the host and preserve logs (journalctl, dmesg, vmcore).
• Check for the KASAN slab trace referencing __bpf_get_stackid or stackmap failures.
• Gather bpftool outputs, the list of loaded BPF programs, and recent configuration changes.
• If running an unpatched kernel, plan an immediate patch-and-reboot on critical hosts following your change-control procedures.
• If patching is delayed, disable unprivileged BPF and restrict capabilities; monitor for recurrence.
• Share artifacts with your vendor or distro security support for triage and confirm your kernel package mapping to upstream commit(s).

---

Conclusion​

CVE‑2025‑68378 is a concrete example of how increasing kernel programmability — here, eBPF stack-tracing — raises the bar for rigorous bounds checking in core helpers. The bug produced a KASAN-detected slab-out-of-bounds write in __bpf_get_stackid when copying more stack entries than a stackmap bucket can hold. Upstream maintainers shipped a small, targeted fix to clamp and guard the copy operation; the canonical vulnerability records and mailing-list threads document the report, reproducer and patch lifecycle. Operators should install vendor-supplied kernel updates that incorporate the upstream commit as the primary fix. Where that is not immediately possible, hardening unprivileged BPF settings and capability grants, auditing BPF-loading tooling, and monitoring kernel logs for the precise KASAN traces give practical, interim protection. The vulnerability is primarily an availability/corruption issue, but because it is kernel-level memory corruption, it deserves high-priority remediation in any environment that permits untrusted or loosely restricted BPF activity.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center