linux-cve-announce - CVE-2022-50091: locking/csd_lock: Change csdlock_debug from early_param to _

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: <2025061800-CVE-2022-50091-fddc@gregkh>
Date: Wed, 18 Jun 2025 13:02:36 +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-50091: locking/csd_lock: Change csdlock_debug from early_param to __setup

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

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

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

locking/csd_lock: Change csdlock_debug from early_param to __setup

The csdlock_debug kernel-boot parameter is parsed by the
early_param() function csdlock_debug().  If set, csdlock_debug()
invokes static_branch_enable() to enable csd_lock_wait feature, which
triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and
CONFIG_SPARSEMEM_VMEMMAP=n.

With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in
static_key_enable() and returns NULL, resulting in a NULL dereference
because mem_section is initialized only later in sparse_init().

This is also a problem for powerpc because early_param() functions
are invoked earlier than jump_label_init(), also resulting in
static_key_enable() failures.  These failures cause the warning "static
key 'xxx' used before call to jump_label_init()".

Thus, early_param is too early for csd_lock_wait to run
static_branch_enable(), so changes it to __setup to fix these.

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

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

	Issue introduced in 5.13 with commit 8d0968cc6b8ffd8496c2ebffdfdc801f949a85e5 and fixed in 5.15.61 with commit d2cbdbe22b5f190055d2d0ae92e7454479343a30
	Issue introduced in 5.13 with commit 8d0968cc6b8ffd8496c2ebffdfdc801f949a85e5 and fixed in 5.18.18 with commit 05de9e2e33b1625c71aee69e353fe906dd2be88a
	Issue introduced in 5.13 with commit 8d0968cc6b8ffd8496c2ebffdfdc801f949a85e5 and fixed in 5.19.2 with commit b480d1e9a8c11ecc1c99dc01814b28e3103bd0a0
	Issue introduced in 5.13 with commit 8d0968cc6b8ffd8496c2ebffdfdc801f949a85e5 and fixed in 6.0 with commit 9c9b26b0df270d4f9246e483a44686fca951a29c

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-50091
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/smp.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/d2cbdbe22b5f190055d2d0ae92e7454479343a30
	https://git.kernel.org/stable/c/05de9e2e33b1625c71aee69e353fe906dd2be88a
	https://git.kernel.org/stable/c/b480d1e9a8c11ecc1c99dc01814b28e3103bd0a0
	https://git.kernel.org/stable/c/9c9b26b0df270d4f9246e483a44686fca951a29c