CVE-2022-49067

powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit

MEDIUM
5.5
CVSS Score
Published: February 26, 2025 at 01:54 AM UTC
Updated: June 17, 2026 at 05:16 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.3%

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]

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 5.4.1904.4 ≤ v < 5.10.1114.4 ≤ v < 5.15.344.4 ≤ v < 5.16.204.4 ≤ v < 5.17.34.4 ≤ v < 5.184.4 ≤ v < 5.4.1905.11 ≤ v < 5.15.345.16 ≤ v < 5.16.205.17 ≤ v < 5.17.35.5 ≤ v < 5.10.1114.45.18 rc1ffda09a9941c18d9f08d1176d55588d505f62912
Vendor states this is fixed in a3727c25eacd7e437c4f560957fa3a376fe93e6b (fixed)
Vendor states this is fixed in cbc065efcba000ad8f615f506ebe61b6d3c5145b (fixed)
Vendor states this is fixed in d36febbcd537fcc50284e8b89609632d0146529f (fixed)
Vendor states this is fixed in deab81144d5a043f42804207fb76cfbd8a806978 (fixed)
Vendor states this is fixed in fddb88bd266f4513abab7c36bca98935c9148a98 (fixed)
Vendor states this is fixed in ffa0b64e3be58519ae472ea29a1a1ad681e32f48 (fixed)
Vendor states this is fixed in 4.4 (unaffected)
Vendor states this is fixed in 5.10.111 (unaffected)
Vendor states this is fixed in 5.15.34 (unaffected)
Vendor states this is fixed in 5.16.20 (unaffected)
Vendor states this is fixed in 5.17.3 (unaffected)
Vendor states this is fixed in 5.18 (unaffected)
Vendor states this is fixed in 5.4.190 (unaffected)

References (6)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/deab81144d5a043f42804207fb76cfbd8a806978
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/fddb88bd266f4513abab7c36bca98935c9148a98
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/ffa0b64e3be58519ae472ea29a1a1ad681e32f48

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusANALYZED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card