CVE-2022-49067

Medium

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]

Package Linux Kernel
Published 2025-02-26
Last modified 2025-10-14
CVSS version 3.1
Patch available
Yes

CVSS 3.1 score

5.5

out of 10
Medium
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
High
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected versions

Linux kernel versions 4.4 and later are affected. Fixed in 5.4.190, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18 and their respective stable series.

Affected from
≥ 4.4
Fixed in
✓ 5.4.190 5.4.x ✓ 5.10.111 5.10.x ✓ 5.15.34 5.15.x ✓ 5.16.20 5.16.x ✓ 5.17.3 5.17.x ✓ 5.18

References

The following references provide additional information about CVE-2022-49067 including vendor advisories, patch commits, exploit details, and third-party analysis. Links are sourced from the NIST NVD database.

Frequently asked questions

  • What is CVE-2022-49067?

    CVE-2022-49067 is a Medium severity Linux kernel vulnerability with a CVSS score of 5.5 out of 10 . It affects Linux kernel versions from 4.4 onward and has been patched in 5.4.190, 5.10.111, 5.15.34 and others. CVE-2022-49067 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.

  • What is the CVSS score for CVE-2022-49067?

    CVE-2022-49067 has a CVSS score of 5.5 out of 10, rated Medium severity (CVSS 3.1). The vector string is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H .

  • Is there a patch available for CVE-2022-49067?

    Yes — CVE-2022-49067 has been patched. Fixed versions include 5.4.190, 5.10.111, 5.15.34 and others. If you are running Linux kernel 4.4 or later up to the fix versions, apply the relevant patch for your kernel branch.

  • Is CVE-2022-49067 actively exploited?

    No — CVE-2022-49067 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.