CVE-2022-50661
published 2025-12-09CVE-2022-50661: In the Linux kernel, the following vulnerability has been resolved: seccomp: Move copy_seccomp() to no failure path. Our syzbot instance reported memory leaks…
PriorityP421low5.5
EPSS
0.24%
15.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
seccomp: Move copy_seccomp() to no failure path.
Our syzbot instance reported memory leaks in do_seccomp() [0], similar
to the report [1]. It shows that we miss freeing struct seccomp_filter
and some objects included in it.
We can reproduce the issue with the program below [2] which calls one
seccomp() and two clone() syscalls.
The first clone()d child exits earlier than its parent and sends a
signal to kill it during the second clone(), more precisely before the
fatal_signal_pending() test in copy_process(). When the parent receives
the signal, it has to destroy the embryonic process and return -EINTR to
user space. In the failure path, we have to call seccomp_filter_release()
to decrement the filter's refcount.
Initially, we called it in free_task() called from the failure path, but
the commit 3a15fb6ed92c ("seccomp: release filter after task is fully
dead") moved it to release_task() to notify user space as early as possible
that the filter is no longer used.
To keep the change and current seccomp refcount semantics, let's move
copy_seccomp() just after the signal check and add a WARN_ON_ONCE() in
free_task() for future debugging.
[0]:
unreferenced object 0xffff8880063add00 (size 256):
comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.914s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
do_seccomp (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/seccomp.c:666 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
unreferenced object 0xffffc90000035000 (size 4096):
comm "repro_seccomp", pid 230, jiffies 4294687090 (age 9.915s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 ..........
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.4-1 (bookworm) | linux 6.1.4-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 3a15fb6ed92cb32b0a83f406aa4a96f28c9adbc3 < d4a895e924b486f2a38463114509e1088ef4d7f5 | d4a895e924b486f2a38463114509e1088ef4d7f5 |
| linux | linux | >= 3a15fb6ed92cb32b0a83f406aa4a96f28c9adbc3 < a31a647a3d1073a642c5bbe3457731fb353cb980 | a31a647a3d1073a642c5bbe3457731fb353cb980 |
| linux | linux | >= 3a15fb6ed92cb32b0a83f406aa4a96f28c9adbc3 < 29a69fa075d0577eff1137426669de21187ec182 | 29a69fa075d0577eff1137426669de21187ec182 |
| linux | linux | >= 3a15fb6ed92cb32b0a83f406aa4a96f28c9adbc3 < 5b81f0c6c60e35bf8153230ddfb03ebb14e17986 | 5b81f0c6c60e35bf8153230ddfb03ebb14e17986 |
| linux | linux | >= 3a15fb6ed92cb32b0a83f406aa4a96f28c9adbc3 < a1140cb215fa13dcec06d12ba0c3ee105633b7c4 | a1140cb215fa13dcec06d12ba0c3ee105633b7c4 |
| linux | linux_kernel | >= 0 < 5.10.191-1 | 5.10.191-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 5.11.0 < 5.15.86 | 5.15.86 |
| linux | linux_kernel | >= 5.16.0 < 6.0.16 | 6.0.16 |
| linux | linux_kernel | >= 5.9.0 < 5.10.180 | 5.10.180 |
| linux | linux_kernel | >= 6.1.0 < 6.1.2 | 6.1.2 |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: seccomp: Move copy_seccomp() to no failure path
vendor_redhat·2025-12-09·CVSS 5.5
CVE-2022-50661 [LOW] CWE-911 kernel: seccomp: Move copy_seccomp() to no failure path
kernel: seccomp: Move copy_seccomp() to no failure path
In the Linux kernel, the following vulnerability has been resolved:
seccomp: Move copy_seccomp() to no failure path.
Our syzbot instance reported memory leaks in do_seccomp() [0], similar
to the report [1]. It shows that we miss freeing struct seccomp_filter
and some objects included in it.
We can reproduce the issue with the program below [2] which calls one
seccomp() and two clone() syscalls.
The first clone()d child exits earlier than its parent and sends a
signal to kill it during the second clone(), more precisely before the
fatal_signal_pending() test in copy_process(). When the parent receives
the signal, it has to destroy the embryonic process and return -EINTR to
user space. In the failure path, we have to call seccomp_filte
Debian
CVE-2022-50661: linux - In the Linux kernel, the following vulnerability has been resolved: seccomp: Mo...
vendor_debian·2022
CVE-2022-50661 CVE-2022-50661: linux - In the Linux kernel, the following vulnerability has been resolved: seccomp: Mo...
In the Linux kernel, the following vulnerability has been resolved: seccomp: Move copy_seccomp() to no failure path. Our syzbot instance reported memory leaks in do_seccomp() [0], similar to the report [1]. It shows that we miss freeing struct seccomp_filter and some objects included in it. We can reproduce the issue with the program below [2] which calls one seccomp() and two clone() syscalls. The first clone()d child exits earlier than its parent and sends a signal to kill it during the second clone(), more precisely before the fatal_signal_pending() test in copy_process(). When the parent receives the signal, it has to destroy the embryonic process and return -EINTR to user space. In the failure path, we have to call seccomp_filter_release() to decrement the filter's refcount. Initially
GHSA
GHSA-256c-6mf5-7f9p: In the Linux kernel, the following vulnerability has been resolved:
seccomp: Move copy_seccomp() to no failure path
ghsa_unreviewed·2025-12-09
CVE-2022-50661 GHSA-256c-6mf5-7f9p: In the Linux kernel, the following vulnerability has been resolved:
seccomp: Move copy_seccomp() to no failure path
In the Linux kernel, the following vulnerability has been resolved:
seccomp: Move copy_seccomp() to no failure path.
Our syzbot instance reported memory leaks in do_seccomp() [0], similar
to the report [1]. It shows that we miss freeing struct seccomp_filter
and some objects included in it.
We can reproduce the issue with the program below [2] which calls one
seccomp() and two clone() syscalls.
The first clone()d child exits earlier than its parent and sends a
signal to kill it during the second clone(), more precisely before the
fatal_signal_pending() test in copy_process(). When the parent receives
the signal, it has to destroy the embryonic process and return -EINTR to
user space. In the failure path, we have to call seccomp_filter_release()
to decrement the filter's refcount.
Init
OSV
seccomp: Move copy_seccomp() to no failure path.
osv·2025-12-09
CVE-2022-50661 seccomp: Move copy_seccomp() to no failure path.
seccomp: Move copy_seccomp() to no failure path.
In the Linux kernel, the following vulnerability has been resolved:
seccomp: Move copy_seccomp() to no failure path.
Our syzbot instance reported memory leaks in do_seccomp() [0], similar
to the report [1]. It shows that we miss freeing struct seccomp_filter
and some objects included in it.
We can reproduce the issue with the program below [2] which calls one
seccomp() and two clone() syscalls.
The first clone()d child exits earlier than its parent and sends a
signal to kill it during the second clone(), more precisely before the
fatal_signal_pending() test in copy_process(). When the parent receives
the signal, it has to destroy the embryonic process and return -EINTR to
user space. In the failure path, we have to call seccomp_filter_r
OSV
CVE-2022-50661: In the Linux kernel, the following vulnerability has been resolved: seccomp: Move copy_seccomp() to no failure path
osv·2025-12-09
CVE-2022-50661 CVE-2022-50661: In the Linux kernel, the following vulnerability has been resolved: seccomp: Move copy_seccomp() to no failure path
In the Linux kernel, the following vulnerability has been resolved: seccomp: Move copy_seccomp() to no failure path. Our syzbot instance reported memory leaks in do_seccomp() [0], similar to the report [1]. It shows that we miss freeing struct seccomp_filter and some objects included in it. We can reproduce the issue with the program below [2] which calls one seccomp() and two clone() syscalls. The first clone()d child exits earlier than its parent and sends a signal to kill it during the second clone(), more precisely before the fatal_signal_pending() test in copy_process(). When the parent receives the signal, it has to destroy the embryonic process and return -EINTR to user space. In the failure path, we have to call seccomp_filter_release() to decrement the filter's refcount. Initially
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/29a69fa075d0577eff1137426669de21187ec182https://git.kernel.org/stable/c/5b81f0c6c60e35bf8153230ddfb03ebb14e17986https://git.kernel.org/stable/c/a1140cb215fa13dcec06d12ba0c3ee105633b7c4https://git.kernel.org/stable/c/a31a647a3d1073a642c5bbe3457731fb353cb980https://git.kernel.org/stable/c/d4a895e924b486f2a38463114509e1088ef4d7f5
2025-12-09
Published