CVE-2025-21834: seccomp: passthrough uretprobe systemcall without filtering
In the Linux kernel, the following vulnerability has been resolved:
seccomp: passthrough uretprobe systemcall without filtering
When attaching uretprobes to processes running inside docker, the attached
process is segfaulted when encountering the retprobe.
The reason is that now that uretprobe is a system call the default seccomp
filters in docker block it as they only allow a specific set of known
syscalls. This is true for other userspace applications which use seccomp
to control their syscall surface.
Since uretprobe is a "kernel implementation detail" system call which is
not used by userspace application code directly, it is impractical and
there's very little point in forcing all userspace applications to
explicitly allow it in order to avoid crashing tracked processes.
Pass this systemcall through seccomp without depending on configuration.
Note: uretprobe is currently only x86_64 and isn't expected to ever be
supported in i386.
[kees: minimized changes for easier backporting, tweaked commit log]
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can crash processes being monitored with uretprobes when seccomp filters block the uretprobe system call. Docker default seccomp filters are specifically mentioned. Business impact is mainly availability and reliability for containerized workloads using tracing or profiling, not confirmed data theft or privilege escalation.
Executive priority
Treat this as a targeted reliability patch for Linux container and observability environments. It does not have confirmed exploitation or a published CVSS score in the provided data, but it can disrupt monitored workloads and should be included in normal kernel patch cycles.
Technical view
The kernel made uretprobe a syscall, but seccomp allowlists such as Docker defaults did not recognize it. When a traced process encountered the return probe, seccomp blocked the implementation-detail syscall and the process segfaulted. The fix passes this syscall through seccomp without user configuration. The source notes x86_64 scope only.
Likely exposure
Exposure is most likely on Linux hosts running containerized or seccomp-confined workloads where uretprobes are attached for tracing, profiling, observability, or security monitoring. Systems not using uretprobes or not running affected kernel versions appear less exposed based on the provided sources.
Exploitation context
No active exploitation is reported in the provided sources, and the CVE is not marked KEV. The scenario described requires uretprobe attachment to a seccomp-filtered process, causing a crash when the probe is hit. Evidence supports reliability impact, not weaponized exploitation.
Researcher notes
The key behavior is a seccomp policy mismatch around a kernel implementation-detail syscall. The public record lacks CVSS, CWE, and detailed affected range semantics. Validate against exact kernel stable commits and distribution backports before declaring exposure or closure.
Mitigation direction
Review vendor kernel advisories for patched builds containing the referenced stable commits.
Prioritize kernel updates on Docker or seccomp-heavy hosts using tracing or profiling.
Avoid assuming Docker seccomp profile edits are the long-term fix; source says kernel passthrough is intended.
Monitor affected workloads for unexplained segfaults during uretprobe-based instrumentation.
Validation and detection
Inventory Linux kernel versions on hosts running Docker or other seccomp-confined workloads.
Identify observability, tracing, profiling, or security tools that attach uretprobes.
Check whether deployed kernels include the referenced stable kernel fixes.
Correlate process segfaults with uretprobe activity in containerized workloads.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
description · low confidence lookup
Container behavior lookup
The affected technology mentions containers, so container-specific ATT&CK technique review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Mar 6, 2025, 16:22 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.