Skip to content
Heist/ feed
Back to feed
UnratedFix available

seccomp: passthrough uretprobe systemcall without filtering

Type: advisorySources: OSV

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]

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.14, 6.13.3
CVEs
CVE-2025-21834
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 19:04 UTC · Revision 1

Source evidence

seccomp: passthrough uretprobe systemcall without filtering

core-osv · Original source

Published 6 Mar 2025, 16:22 UTC

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]

osv:CVE-2025-21834

Kernel

Fixed versions: 6.12.14, 6.13.3

Complete source record
{
  "id": "ca891b62602d74de9f28771dffbf5a0ceeac9eff1743363d8964acd6cdd20510",
  "url": "https://osv.dev/vulnerability/CVE-2025-21834",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "seccomp: passthrough uretprobe systemcall without filtering",
    "summary": "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]",
    "evidence": "osv:CVE-2025-21834",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.14",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.13.3",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "CVE-2025-21834",
      "aliases": [
        "CVE-2025-21834"
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "ff474a78cef5cb5f32be52fe25b78441327a2e7c"
                },
                {
                  "fixed": "5a262628f4cf2437d863fe41f9d427177b87664c"
                },
                {
                  "fixed": "fa80018aa5be10c35e9fa896b7b4061a8dce3eed"
                },
                {
                  "fixed": "cf6cb56ef24410fb5308f9655087f1eddf4452e6"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21834.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.11.0"
                },
                {
                  "fixed": "6.12.14"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.13.3"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21834.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:38.667714443Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/5a262628f4cf2437d863fe41f9d427177b87664c",
        "https://git.kernel.org/stable/c/cf6cb56ef24410fb5308f9655087f1eddf4452e6",
        "https://git.kernel.org/stable/c/fa80018aa5be10c35e9fa896b7b4061a8dce3eed",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/21xxx/CVE-2025-21834.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-21834",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/21xxx/CVE-2025-21834.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2025-21834",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 505975,
  "published_at": "2025-03-06T16:22:35.49+00:00"
}