CVE-2022-49067: Vulnerability in Linux Linux
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]
AI Analysis
Technical Summary
CVE-2022-49067 is a vulnerability in the Linux kernel specifically affecting the PowerPC architecture, particularly the 64-bit Book3E and 32-bit variants. The issue arises from incorrect validation of virtual addresses in the function virt_addr_valid(). On 64-bit Book3E systems, the vmalloc space starts at a high virtual address (0x8000000000000000). Due to the behavior of the __pa() macro, which translates virtual addresses to physical addresses, this high vmalloc address incorrectly maps to physical address zero. Consequently, virt_addr_valid() returns true for vmalloc addresses that should be invalid, as vmalloc addresses alias with valid page frame numbers (PFNs). This incorrect validation can cause kernel bugs, particularly with hardened usercopy operations that protect against kernel memory exposure. The vulnerability was demonstrated by a kernel BUG triggered when running ethtool on eth0, where the kernel detected an invalid memory exposure attempt and panicked. The root cause is that data allocated by vmalloc() is mistakenly considered valid by virt_addr_valid(), leading to unsafe memory operations and kernel crashes. The fix involves adding upper limit checks in virt_addr_valid() to ensure addresses above PAGE_OFFSET and below high_memory are correctly validated, preventing false positives for vmalloc space. For 32-bit PowerPC, a similar problem with high memory was previously fixed but caused regressions, so the current patch reverts that and applies more precise checks. The vulnerability does not affect 64-bit Book3S systems due to differences in address translation. This flaw is subtle and architecture-specific, impacting kernel memory management and potentially causing denial of service via kernel panic when certain ioctl operations are performed. No known exploits are reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations running Linux on PowerPC 64-bit Book3E or 32-bit systems, this vulnerability could lead to unexpected kernel panics and denial of service conditions, especially when using network diagnostic tools like ethtool. This could disrupt critical infrastructure, telecommunications equipment, or embedded systems relying on affected Linux kernels. Confidentiality and integrity impacts are limited since the issue primarily causes kernel crashes rather than direct memory corruption or privilege escalation. However, the denial of service could affect availability of services, particularly in industrial, telecom, or research environments where PowerPC-based Linux systems are deployed. Organizations using hardened kernels with usercopy protections might experience stability issues or service interruptions. The lack of known exploits reduces immediate risk, but unpatched systems remain vulnerable to accidental or targeted triggering of kernel panics, impacting operational continuity.
Mitigation Recommendations
European organizations should ensure that Linux kernels running on PowerPC 64-bit Book3E and 32-bit architectures are updated to include the patch that corrects virt_addr_valid() behavior. Since the vulnerability is architecture-specific, verifying system architecture is critical. Kernel upgrades should be prioritized in environments where ethtool or similar ioctl-based tools are used, as these can trigger the bug. Additionally, organizations should audit their use of vmalloc memory and hardened usercopy features to identify potential triggers. Testing kernel updates in staging environments before production deployment is recommended to avoid regressions. For embedded or specialized systems where kernel updates are delayed, consider restricting access to ioctl interfaces or limiting use of vulnerable tools as a temporary workaround. Monitoring kernel logs for BUG messages related to usercopy or virt_addr_valid() can help detect attempts to trigger the vulnerability. Collaboration with Linux distribution vendors to obtain timely patches and backports is essential for maintaining security and stability.
Affected Countries
Germany, France, United Kingdom, Netherlands, Italy, Sweden, Finland
CVE-2022-49067: Vulnerability in Linux Linux
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]
AI-Powered Analysis
Technical Analysis
CVE-2022-49067 is a vulnerability in the Linux kernel specifically affecting the PowerPC architecture, particularly the 64-bit Book3E and 32-bit variants. The issue arises from incorrect validation of virtual addresses in the function virt_addr_valid(). On 64-bit Book3E systems, the vmalloc space starts at a high virtual address (0x8000000000000000). Due to the behavior of the __pa() macro, which translates virtual addresses to physical addresses, this high vmalloc address incorrectly maps to physical address zero. Consequently, virt_addr_valid() returns true for vmalloc addresses that should be invalid, as vmalloc addresses alias with valid page frame numbers (PFNs). This incorrect validation can cause kernel bugs, particularly with hardened usercopy operations that protect against kernel memory exposure. The vulnerability was demonstrated by a kernel BUG triggered when running ethtool on eth0, where the kernel detected an invalid memory exposure attempt and panicked. The root cause is that data allocated by vmalloc() is mistakenly considered valid by virt_addr_valid(), leading to unsafe memory operations and kernel crashes. The fix involves adding upper limit checks in virt_addr_valid() to ensure addresses above PAGE_OFFSET and below high_memory are correctly validated, preventing false positives for vmalloc space. For 32-bit PowerPC, a similar problem with high memory was previously fixed but caused regressions, so the current patch reverts that and applies more precise checks. The vulnerability does not affect 64-bit Book3S systems due to differences in address translation. This flaw is subtle and architecture-specific, impacting kernel memory management and potentially causing denial of service via kernel panic when certain ioctl operations are performed. No known exploits are reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations running Linux on PowerPC 64-bit Book3E or 32-bit systems, this vulnerability could lead to unexpected kernel panics and denial of service conditions, especially when using network diagnostic tools like ethtool. This could disrupt critical infrastructure, telecommunications equipment, or embedded systems relying on affected Linux kernels. Confidentiality and integrity impacts are limited since the issue primarily causes kernel crashes rather than direct memory corruption or privilege escalation. However, the denial of service could affect availability of services, particularly in industrial, telecom, or research environments where PowerPC-based Linux systems are deployed. Organizations using hardened kernels with usercopy protections might experience stability issues or service interruptions. The lack of known exploits reduces immediate risk, but unpatched systems remain vulnerable to accidental or targeted triggering of kernel panics, impacting operational continuity.
Mitigation Recommendations
European organizations should ensure that Linux kernels running on PowerPC 64-bit Book3E and 32-bit architectures are updated to include the patch that corrects virt_addr_valid() behavior. Since the vulnerability is architecture-specific, verifying system architecture is critical. Kernel upgrades should be prioritized in environments where ethtool or similar ioctl-based tools are used, as these can trigger the bug. Additionally, organizations should audit their use of vmalloc memory and hardened usercopy features to identify potential triggers. Testing kernel updates in staging environments before production deployment is recommended to avoid regressions. For embedded or specialized systems where kernel updates are delayed, consider restricting access to ioctl interfaces or limiting use of vulnerable tools as a temporary workaround. Monitoring kernel logs for BUG messages related to usercopy or virt_addr_valid() can help detect attempts to trigger the vulnerability. Collaboration with Linux distribution vendors to obtain timely patches and backports is essential for maintaining security and stability.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2025-02-26T01:49:39.244Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d982fc4522896dcbe6a64
Added to database: 5/21/2025, 9:09:03 AM
Last enriched: 7/1/2025, 1:55:12 AM
Last updated: 7/28/2025, 3:17:41 PM
Views: 9
Related Threats
CVE-2025-8929: SQL Injection in code-projects Medical Store Management System
MediumCVE-2025-8928: SQL Injection in code-projects Medical Store Management System
MediumCVE-2025-34154: CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') in Synergetic Data Systems Inc. UnForm Server Manager
CriticalCVE-2025-8927: Improper Restriction of Excessive Authentication Attempts in mtons mblog
MediumCVE-2025-43988: n/a
CriticalActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.