CVE-2026-72112: Linux kernel · io_uring/bpf-ops: reject re-registration of an already-bound ops
Affects Linux kernelSource GCVE Database
Not known to be exploited · CVSS 7.8 High.
Data as of 26 Oct 2026, 15:59 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 17 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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
AI-suggested
The vulnerability description indicates a fix by rejecting registration when ops->priv is already set, but no explicit patch or vendor advisory is provided in the input data.
Description
In the Linux kernel, the following vulnerability has been resolved: io_uring/bpf-ops: reject re-registration of an already-bound ops io_install_bpf() only rejects a second registration on the ctx side (ctx->bpf_ops) and sets the per-map back-pointer ops->priv unconditionally. The struct_ops link path never advances a map past BPF_STRUCT_OPS_STATE_READY, so the same io_uring_bpf_ops map can be registered more than once, and bpf_io_reg() re-resolves the target ring via fget(ops->ring_fd) on every call. A caller can therefore point the same ring_fd at a different io_ring_ctx between two BPF_LINK_CREATE calls. The second registration passes the ctx->bpf_ops check (the new ctx has none) and overwrites ops->priv, orphaning the first ctx. Teardown (io_eject_bpf()/bpf_io_unreg()) only reaches a ctx through ops->priv, so the orphaned ctx is never torn down: its ctx->loop_step keeps pointing into the struct_ops trampoline, which is freed once the map is gone. A later io_uring_enter() on the orphaned ring then calls the dangling ctx->loop_step from io_run_loop() -- a use-after-free of freed executable memory, reachable by a task with CAP_BPF + CAP_PERFMON. Reject registration when ops->priv is already set, as hid_bpf_reg() does for its struct_ops.
References
- nvd.nist.gov/vuln/detail/CVE-2026-72112 (opens in a new tab)
- git.kernel.org/stable/c/0639ea767fe04c288a8d6cb826100fe3d95d4936 (opens in a new tab)
- git.kernel.org/stable/c/3afc64c61ce906a04f073ca350b46de10e8302f9 (opens in a new tab)
- ubuntu.com/security/CVE-2026-72112 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2026-72112 (opens in a new tab)
- git.kernel.org/linus/3afc64c61ce906a04f073ca350b46de10e8302f9 (opens in a new tab)