[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025091547-CVE-2022-50239-3908@gregkh>
Date: Mon, 15 Sep 2025 16:01:47 +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-50239: cpufreq: qcom: fix writes in read-only memory region
From: Greg Kroah-Hartman <gregkh@...nel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: qcom: fix writes in read-only memory region
This commit fixes a kernel oops because of a write in some read-only memory:
[ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8
..snip..
[ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP
..snip..
[ 9.269161] Call trace:
[ 9.276271] __memcpy+0x5c/0x230
[ 9.278531] snprintf+0x58/0x80
[ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190
[ 9.284869] qcom_cpufreq_probe+0xc8/0x39c
..snip..
The following line defines a pointer that point to a char buffer stored
in read-only memory:
char *pvs_name = "speedXX-pvsXX-vXX";
This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the
XX values get overridden by the qcom_cpufreq_krait_name_version function. Since
the template is actually stored in read-only memory, when the function
executes the following call we get an oops:
snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d",
speed, pvs, pvs_ver);
To fix this issue, we instead store the template name onto the stack by
using the following syntax:
char pvs_name_buffer[] = "speedXX-pvsXX-vXX";
Because the `pvs_name` needs to be able to be assigned to NULL, the
template buffer is stored in the pvs_name_buffer and not under the
pvs_name variable.
The Linux kernel CVE team has assigned CVE-2022-50239 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.7 with commit a8811ec764f95a04ba82f6f457e28c5e9e36e36b and fixed in 5.10.152 with commit 794ded0bc461287a268bed21fea2eebb6e5d232c
Issue introduced in 5.7 with commit a8811ec764f95a04ba82f6f457e28c5e9e36e36b and fixed in 5.15.76 with commit 14d260f94ff89543597ffea13db8b277a810e08e
Issue introduced in 5.7 with commit a8811ec764f95a04ba82f6f457e28c5e9e36e36b and fixed in 6.0.6 with commit b74ee4e301ca01e431e240c046173332966e2431
Issue introduced in 5.7 with commit a8811ec764f95a04ba82f6f457e28c5e9e36e36b and fixed in 6.1 with commit 01039fb8e90c9cb684430414bff70cea9eb168c5
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-50239
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:
drivers/cpufreq/qcom-cpufreq-nvmem.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/794ded0bc461287a268bed21fea2eebb6e5d232c
https://git.kernel.org/stable/c/14d260f94ff89543597ffea13db8b277a810e08e
https://git.kernel.org/stable/c/b74ee4e301ca01e431e240c046173332966e2431
https://git.kernel.org/stable/c/01039fb8e90c9cb684430414bff70cea9eb168c5
Powered by blists - more mailing lists