CVE-2022-49067

Source
https://cve.org/CVERecord?id=CVE-2022-49067
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49067.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2022-49067
Downstream
Published
2025-02-26T01:54:34.862Z
Modified
2026-04-11T12:43:30.658700Z
Summary
powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit
Details

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

powerpc: Fix virtaddrvalid() 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 virttopfn(0x8000000000000000) == 0, and therefore virtaddrvalid(0x8000000000000000) == true

Which is wrong, virtaddrvalid() should be false for vmalloc space. In fact all vmalloc addresses that alias with a valid PFN will return true from virtaddrvalid(). 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(), virtaddrvalid(ptr) will return true on 64-bit Book3E, which leads to the panic.

As commit 4dd7554a6456 ("powerpc/64: Add VIRTUALBUGON checks for __va and __pa addresses") does, make sure the virt addr above PAGEOFFSET in the virtaddrvalid() for 64-bit, also add upper limit check to make sure the virt is below highmemory.

Meanwhile, for 32-bit PAGEOFFSET is the virtual address of the start of lowmem, highmemory 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 virtaddrvalid().

For 64-bit Book3S the extra checks are not necessary, the combination of virttopfn() and pfn_valid() should yield the correct result, but they are harmless.

[mpe: Add additional change log detail]

Database specific
{
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49067.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
ffda09a9941c18d9f08d1176d55588d505f62912
Fixed
deab81144d5a043f42804207fb76cfbd8a806978
Fixed
d36febbcd537fcc50284e8b89609632d0146529f
Fixed
fddb88bd266f4513abab7c36bca98935c9148a98
Fixed
a3727c25eacd7e437c4f560957fa3a376fe93e6b
Fixed
cbc065efcba000ad8f615f506ebe61b6d3c5145b
Fixed
ffa0b64e3be58519ae472ea29a1a1ad681e32f48

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49067.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
4.4.0
Fixed
5.4.190
Type
ECOSYSTEM
Events
Introduced
5.5.0
Fixed
5.10.111
Type
ECOSYSTEM
Events
Introduced
5.11.0
Fixed
5.15.34
Type
ECOSYSTEM
Events
Introduced
5.16.0
Fixed
5.16.20
Type
ECOSYSTEM
Events
Introduced
5.17.0
Fixed
5.17.3

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49067.json"