CVE-2022-49067

published 2025-02-26

CVE-2022-49067: 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…

Priority P4 21 medium 5.5 CVSS 3.1

AV L AC L PR L UI N S U C N I N A H

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 m

Affected

18 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 5.17.3-1 (bookworm)	linux 5.17.3-1 (bookworm)
linux	linux	—	—
linux	linux	>= ffda09a9941c18d9f08d1176d55588d505f62912 < deab81144d5a043f42804207fb76cfbd8a806978	deab81144d5a043f42804207fb76cfbd8a806978
linux	linux	>= ffda09a9941c18d9f08d1176d55588d505f62912 < d36febbcd537fcc50284e8b89609632d0146529f	d36febbcd537fcc50284e8b89609632d0146529f
linux	linux	>= ffda09a9941c18d9f08d1176d55588d505f62912 < fddb88bd266f4513abab7c36bca98935c9148a98	fddb88bd266f4513abab7c36bca98935c9148a98
linux	linux	>= ffda09a9941c18d9f08d1176d55588d505f62912 < a3727c25eacd7e437c4f560957fa3a376fe93e6b	a3727c25eacd7e437c4f560957fa3a376fe93e6b
linux	linux	>= ffda09a9941c18d9f08d1176d55588d505f62912 < cbc065efcba000ad8f615f506ebe61b6d3c5145b	cbc065efcba000ad8f615f506ebe61b6d3c5145b
linux	linux	>= ffda09a9941c18d9f08d1176d55588d505f62912 < ffa0b64e3be58519ae472ea29a1a1ad681e32f48	ffa0b64e3be58519ae472ea29a1a1ad681e32f48
linux	linux_kernel	< 5.4.190	5.4.190
linux	linux_kernel	—	—
linux	linux_kernel	>= 0 < 5.10.113-1	5.10.113-1
linux	linux_kernel	>= 0 < 5.17.3-1	5.17.3-1
linux	linux_kernel	>= 0 < 5.17.3-1	5.17.3-1
linux	linux_kernel	>= 0 < 5.17.3-1	5.17.3-1
linux	linux_kernel	>= 5.11 < 5.15.34	5.15.34
linux	linux_kernel	>= 5.16 < 5.16.20	5.16.20
linux	linux_kernel	>= 5.17 < 5.17.3	5.17.3
linux	linux_kernel	>= 5.5 < 5.10.111	5.10.111

CVSS provenance

nvd v3.1 5.5 MEDIUM CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

osv 5.5 MEDIUM

vendor_debian 5.5 MEDIUM

vendor_redhat 5.5 MEDIUM

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.