Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: io_uring/bpf-ops: reject re-registration of an already-bound ops… (CVE-2026-72112)
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.
AI Analysis
Technical Summary
The vulnerability in the Linux kernel io_uring subsystem involves the io_install_bpf() function, which only rejects a second registration on the same context side but does not prevent re-registration of the same io_uring_bpf_ops map multiple times. This allows a caller to point the same ring_fd at different io_ring_ctx instances between BPF_LINK_CREATE calls. The second registration overwrites the ops->priv pointer, orphaning the first context. Since teardown functions rely on ops->priv to clean up, the orphaned context remains active with a dangling pointer to freed executable memory. Subsequent io_uring_enter() calls trigger a use-after-free condition, exploitable by tasks with CAP_BPF and CAP_PERFMON privileges. The fix involves rejecting registration when ops->priv is already set, preventing multiple registrations of the same ops.
Potential Impact
This vulnerability enables a local attacker with CAP_BPF and CAP_PERFMON capabilities to execute use-after-free on freed executable memory within the kernel, potentially leading to privilege escalation or arbitrary code execution in kernel context.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. 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.
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: io_uring/bpf-ops: reject re-registration of an already-bound ops… (CVE-2026-72112)
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.
CVSS v3.1
Score 7.8high
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in the Linux kernel io_uring subsystem involves the io_install_bpf() function, which only rejects a second registration on the same context side but does not prevent re-registration of the same io_uring_bpf_ops map multiple times. This allows a caller to point the same ring_fd at different io_ring_ctx instances between BPF_LINK_CREATE calls. The second registration overwrites the ops->priv pointer, orphaning the first context. Since teardown functions rely on ops->priv to clean up, the orphaned context remains active with a dangling pointer to freed executable memory. Subsequent io_uring_enter() calls trigger a use-after-free condition, exploitable by tasks with CAP_BPF and CAP_PERFMON privileges. The fix involves rejecting registration when ops->priv is already set, preventing multiple registrations of the same ops.
Potential Impact
This vulnerability enables a local attacker with CAP_BPF and CAP_PERFMON capabilities to execute use-after-free on freed executable memory within the kernel, potentially leading to privilege escalation or arbitrary code execution in kernel context.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. 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.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-wgmw-xwr6-63ww
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-72112"]
Threat ID: 6a808b76bf8831d53950012c
Added to database: 08/15/2026, 15:53:26 UTC
Last enriched: 08/15/2026, 16:58:02 UTC
Last updated: 09/30/2026, 06:54:40 UTC
Views: 32
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.