[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025022654-CVE-2022-49067-94d7@gregkh>
Date: Wed, 26 Feb 2025 02:54:32 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-49067: powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit
mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.
Because of the way __pa() works we have:
__pa(0x8000000000000000) == 0, and therefore
virt_to_pfn(0x8000000000000000) == 0, and therefore
virt_addr_valid(0x8000000000000000) == true
Which is wrong, virt_addr_valid() should be false for vmalloc space.
In fact all vmalloc addresses that alias with a valid PFN will return
true from virt_addr_valid(). That can cause bugs with hardened usercopy
as described below by Kefeng Wang:
When running ethtool eth0 on 64-bit Book3E, a BUG occurred:
usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
kernel BUG at mm/usercopy.c:99
...
usercopy_abort+0x64/0xa0 (unreliable)
__check_heap_object+0x168/0x190
__check_object_size+0x1a0/0x200
dev_ethtool+0x2494/0x2b20
dev_ioctl+0x5d0/0x770
sock_do_ioctl+0xf0/0x1d0
sock_ioctl+0x3ec/0x5a0
__se_sys_ioctl+0xf0/0x160
system_call_exception+0xfc/0x1f0
system_call_common+0xf8/0x200
The code shows below,
data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
on 64-bit Book3E, which leads to the panic.
As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in
the virt_addr_valid() for 64-bit, also add upper limit check to make
sure the virt is below high_memory.
Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start
of lowmem, high_memory is the upper low virtual address, the check is
suitable for 32-bit, this will fix the issue mentioned in commit
602946ec2f90 ("powerpc: Set max_mapnr correctly") too.
On 32-bit there is a similar problem with high memory, that was fixed in
commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that
commit breaks highmem and needs to be reverted.
We can't easily fix __pa(), we have code that relies on its current
behaviour. So for now add extra checks to virt_addr_valid().
For 64-bit Book3S the extra checks are not necessary, the combination of
virt_to_pfn() and pfn_valid() should yield the correct result, but they
are harmless.
[mpe: Add additional change log detail]
The Linux kernel CVE team has assigned CVE-2022-49067 to this issue.
Affected and fixed versions
===========================
Fixed in 5.4.190 with commit deab81144d5a043f42804207fb76cfbd8a806978
Fixed in 5.10.111 with commit d36febbcd537fcc50284e8b89609632d0146529f
Fixed in 5.15.34 with commit fddb88bd266f4513abab7c36bca98935c9148a98
Fixed in 5.16.20 with commit a3727c25eacd7e437c4f560957fa3a376fe93e6b
Fixed in 5.17.3 with commit cbc065efcba000ad8f615f506ebe61b6d3c5145b
Fixed in 5.18 with commit ffa0b64e3be58519ae472ea29a1a1ad681e32f48
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-49067
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/powerpc/include/asm/page.h
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/deab81144d5a043f42804207fb76cfbd8a806978
https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f
https://git.kernel.org/stable/c/fddb88bd266f4513abab7c36bca98935c9148a98
https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b
https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b
https://git.kernel.org/stable/c/ffa0b64e3be58519ae472ea29a1a1ad681e32f48
Powered by blists - more mailing lists