CVE-2022-49067 in Linux
Summary
by MITRE • 02/26/2025
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]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2025
The vulnerability described in CVE-2022-49067 affects the Linux kernel's powerpc architecture implementation, specifically within the virtual address validation mechanism for 64-bit Book3E and 32-bit systems. This flaw manifests in the virt_addr_valid() function which incorrectly identifies vmalloc memory addresses as valid virtual addresses, leading to potential kernel memory exposure and system instability. The issue stems from the interaction between the __pa() macro and the virtual to physical address conversion logic on powerpc platforms, where vmalloc space starting at 0x8000000000000000 gets mapped to physical address 0, causing virt_addr_valid() to return true erroneously.
The technical root cause involves the powerpc architecture's memory management model where the __pa() macro's behavior creates false positives in virtual address validation. Specifically, when a vmalloc address like 0x8000000000000000 is passed to __pa(), it returns 0 due to the addressing scheme, which then maps through virt_to_pfn() to return 0, and finally virt_addr_valid() incorrectly evaluates this as a valid address. This affects the hardened usercopy functionality that relies on virt_addr_valid() to determine memory access boundaries, creating a security vulnerability where kernel memory could be exposed to user space through improper validation checks. The flaw aligns with CWE-125: Out-of-bounds Read, as the validation mechanism fails to properly distinguish between legitimate kernel memory and vmalloc regions that should be excluded from usercopy checks.
The operational impact of this vulnerability is severe, particularly in network driver contexts where ethtool and similar utilities operate. The reported kernel panic demonstrates how a simple userland command can trigger a kernel BUG due to improper address validation. When ethtool attempts to copy data from a vmalloc-allocated buffer, the incorrect virt_addr_valid() result bypasses security checks, leading to a kernel memory exposure attempt detection that results in system panic. This vulnerability affects systems running 64-bit Book3E powerpc kernels and also impacts 32-bit systems where similar vmalloc address aliasing issues occur, potentially compromising system stability and security. The issue is particularly dangerous because it can be triggered by legitimate user-space operations without requiring special privileges, making it a critical concern for system administrators.
Mitigation strategies focus on enhancing the virt_addr_valid() function with additional boundary checks that properly distinguish between valid kernel memory and vmalloc regions. The fix implements checks that ensure virtual addresses above PAGE_OFFSET are properly validated against high_memory limits, preventing vmalloc addresses from being treated as valid kernel memory. For 64-bit Book3E systems, this involves adding upper limit checks to ensure virtual addresses remain below high_memory boundaries, while maintaining compatibility with existing 32-bit logic that already includes appropriate validation. The solution follows ATT&CK technique T1068: Exploitation for Privilege Escalation by addressing a kernel-level vulnerability that could be exploited to gain unauthorized access to kernel memory, though the specific exploit path requires careful manipulation of the virtual address validation logic. The fix is backward compatible with existing code that depends on __pa() behavior while strengthening the security boundaries around memory validation, preventing the specific usercopy panic scenario that was demonstrated in the vulnerability report.