linux-cve-announce - CVE-2025-21834: seccomp: passthrough uretprobe systemcall without filtering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025030635-CVE-2025-21834-d92c@gregkh>
Date: Thu,  6 Mar 2025 17:22:40 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2025-21834: seccomp: passthrough uretprobe systemcall without filtering

Description
===========

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]

The Linux kernel CVE team has assigned CVE-2025-21834 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 6.11 with commit ff474a78cef5cb5f32be52fe25b78441327a2e7c and fixed in 6.12.14 with commit 5a262628f4cf2437d863fe41f9d427177b87664c
	Issue introduced in 6.11 with commit ff474a78cef5cb5f32be52fe25b78441327a2e7c and fixed in 6.13.3 with commit fa80018aa5be10c35e9fa896b7b4061a8dce3eed
	Issue introduced in 6.11 with commit ff474a78cef5cb5f32be52fe25b78441327a2e7c and fixed in 6.14-rc2 with commit cf6cb56ef24410fb5308f9655087f1eddf4452e6

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-21834
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	kernel/seccomp.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/5a262628f4cf2437d863fe41f9d427177b87664c
	https://git.kernel.org/stable/c/fa80018aa5be10c35e9fa896b7b4061a8dce3eed
	https://git.kernel.org/stable/c/cf6cb56ef24410fb5308f9655087f1eddf4452e6