linux-cve-announce - CVE-2022-49990: s390: fix double free of GS and RI CBs on fork() failure

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: <2025061824-CVE-2022-49990-a8af@gregkh>
Date: Wed, 18 Jun 2025 13:00:55 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-49990: s390: fix double free of GS and RI CBs on fork() failure

From: Greg Kroah-Hartman <gregkh@...nel.org>

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

In the Linux kernel, the following vulnerability has been resolved:

s390: fix double free of GS and RI CBs on fork() failure

The pointers for guarded storage and runtime instrumentation control
blocks are stored in the thread_struct of the associated task. These
pointers are initially copied on fork() via arch_dup_task_struct()
and then cleared via copy_thread() before fork() returns. If fork()
happens to fail after the initial task dup and before copy_thread(),
the newly allocated task and associated thread_struct memory are
freed via free_task() -> arch_release_task_struct(). This results in
a double free of the guarded storage and runtime info structs
because the fields in the failed task still refer to memory
associated with the source task.

This problem can manifest as a BUG_ON() in set_freepointer() (with
CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)
when running trinity syscall fuzz tests on s390x. To avoid this
problem, clear the associated pointer fields in
arch_dup_task_struct() immediately after the new task is copied.
Note that the RI flag is still cleared in copy_thread() because it
resides in thread stack memory and that is where stack info is
copied.

The Linux kernel CVE team has assigned CVE-2022-49990 to this issue.

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

	Issue introduced in 4.15 with commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 and fixed in 4.19.257 with commit 25a95303b9e513cd2978aacc385d06e6fec23d07
	Issue introduced in 4.15 with commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 and fixed in 5.4.212 with commit cacd522e6652fbc2dc0cc6ae11c4e30782fef14b
	Issue introduced in 4.15 with commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 and fixed in 5.10.140 with commit 297ae7e87a87a001dd3dfeac1cb26a42fd929708
	Issue introduced in 4.15 with commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 and fixed in 5.15.64 with commit 8195e065abf3df84eb0ad2987e76a40f21d1791c
	Issue introduced in 4.15 with commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 and fixed in 5.19.6 with commit fbdc482d43eda40a70de4b0155843d5472f6de62
	Issue introduced in 4.15 with commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 and fixed in 6.0 with commit 13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9
	Issue introduced in 4.4.105 with commit 9e51ee1b76efc7b5e9404010793a39fde0e03cb7
	Issue introduced in 4.9.68 with commit 232b47b3c88af1da737cd7760f247c4ed58168cf
	Issue introduced in 4.14.5 with commit b8e212c599082896a180a18a0c9bd529526590be

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-2022-49990
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:
	arch/s390/kernel/process.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/25a95303b9e513cd2978aacc385d06e6fec23d07
	https://git.kernel.org/stable/c/cacd522e6652fbc2dc0cc6ae11c4e30782fef14b
	https://git.kernel.org/stable/c/297ae7e87a87a001dd3dfeac1cb26a42fd929708
	https://git.kernel.org/stable/c/8195e065abf3df84eb0ad2987e76a40f21d1791c
	https://git.kernel.org/stable/c/fbdc482d43eda40a70de4b0155843d5472f6de62
	https://git.kernel.org/stable/c/13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9