Skip to main content
VulnerabilityPublished Updated

CVE-2026-53094: Linux kernel · bpf: Fix stale offload->prog pointer after constant blinding

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in c79f8503d83d4665be461fb9e45e215d0380c67b : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in c79f8503d83d4665be461fb9e45e215d0380c67b, a713b72ff88cdab4d5d692908ab1259ada511f4d, a1aa9ef47c299c5bbc30594d3c2f0589edf908e6 +2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 2b3486bc2d237ec345b3942b7be5deabf8c8fed1, < c79f8503d83d4665be461fb9e45e215d0380c67b
Fixed in
  • c79f8503d83d4665be461fb9e45e215d0380c67b
LinuxLinuxAffected
  • ≥ 2b3486bc2d237ec345b3942b7be5deabf8c8fed1, < a713b72ff88cdab4d5d692908ab1259ada511f4d
Fixed in
  • a713b72ff88cdab4d5d692908ab1259ada511f4d
LinuxLinuxAffected
  • ≥ 2b3486bc2d237ec345b3942b7be5deabf8c8fed1, < a1aa9ef47c299c5bbc30594d3c2f0589edf908e6
Fixed in
  • a1aa9ef47c299c5bbc30594d3c2f0589edf908e6
LinuxLinuxAffected
  • ≥ 2b3486bc2d237ec345b3942b7be5deabf8c8fed1, < 059525cf18e69a9313baf947d8898c6ee7ca6b65
Fixed in
  • 059525cf18e69a9313baf947d8898c6ee7ca6b65
LinuxLinuxAffected
  • ≥ 2b3486bc2d237ec345b3942b7be5deabf8c8fed1, < 25484c39d1ec82a0368798d956da3de5039b3fe8
Fixed in
  • 25484c39d1ec82a0368798d956da3de5039b3fe8
LinuxLinuxAffected
  • =6.3
Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stale offload->prog pointer after constant blinding When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes JIT compilation with constant blinding enabled (bpf_jit_harden >= 2), bpf_jit_blind_constants() clones the program. The original prog is then freed in bpf_jit_prog_release_other(), which updates aux->prog to point to the surviving clone, but fails to update offload->prog. This leaves offload->prog pointing to the freed original program. When the network namespace is subsequently destroyed, cleanup_net() triggers bpf_dev_bound_netdev_unregister(), which iterates ondev->progs and calls __bpf_prog_offload_destroy(offload->prog). Accessing the freed prog causes a page fault: BUG: unable to handle page fault for address: ffffc900085f1038 Workqueue: netns cleanup_net RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80 Call Trace: __bpf_offload_dev_netdev_unregister+0x257/0x350 bpf_dev_bound_netdev_unregister+0x4a/0x90 unregister_netdevice_many_notify+0x2a2/0x660 ... cleanup_net+0x21a/0x320 The test sequence that triggers this reliably is: 1. Set net.core.bpf_jit_harden=2 (echo 2 > /proc/sys/net/core/bpf_jit_harden) 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP program on a veth inside a netns (./test_progs -t xdp_metadata) 3. cleanup_net -> page fault in __bpf_prog_offload_destroy Dev-bound-only programs are unique in that they have an offload structure but go through the normal JIT path instead of bpf_prog_offload_compile(). This means they are subject to constant blinding's prog clone-and-replace, while also having offload->prog that must stay in sync. Fix this by updating offload->prog in bpf_jit_prog_release_other(), alongside the existing aux->prog update. Both are back-pointers to the prog that must be kept in sync when the prog is replaced.

References

Community reviews

Loading reviews…