Read the docs
TI-2022-24583 Aliases CVE-2022-49067GHSA-3vm4-73fj-2j43

powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit

Priority LOW 24Published · Updated

Key facts

Attack vector
Local
Privileges required
Low
User interaction
None
Attack complexity
Low
Impact type
—
Confidentiality · integrity · availability
None · None · High
Fix status
Fixed

Attack profile from CVSS 3.1 · NVD. Fix status from CNA.

Summary

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]

Why it matters now

EPSS 0.00262 18th percentileScored 2026-11-07
Fix Fixed Linux (Linux): 5.4.190, 5.10.111, 5.15.34 +3

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
LinuxLinux4.4 and later5.4.190, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18Patch availableCNA
  • Linux VendorLinux Affected 4.4 and later Fixed in 5.4.190, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18 Patch available CNA

CPE configurations NVD · 2

CPEVersionsRoleVendor
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*before 5.4.190; 5.5 to before 5.10.111; 5.11 to before 5.15.34; 5.16 to before 5.16.20; 5.17 to before 5.17.3VulnerableLinux
cpe:2.3:o:linux:linux_kernel:5.18:rc1:*:*:*:*:*:*5.18 rc1VulnerableLinux
  • cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions before 5.4.190; 5.5 to before 5.10.111; 5.11 to before 5.15.34; 5.16 to before 5.16.20; 5.17 to before 5.17.3 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:5.18:rc1:*:*:*:*:*:* Versions 5.18 rc1 Vulnerable ·Linux

Remediation

  • Fix · CNA Linux (Linux) Fixed in 5.4.190, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18

Vendor assessments

Red Hat

Red Hat's page for this CVE →

Not affected: 5 products
  • Red Hat Enterprise Linux 10
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9

Timeline

  1. 2026-10-02 Threatist record created from CVE-2022-49067
  2. 2026-10-03 Alias added: GHSA-3vm4-73fj-2j43

References

  • TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
  • TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
  • TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
  • TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
  • TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
  • TI-2021-05514 Heap Out-Of-Bounds Write in Netfilter IP6T_SO_SET_REPLACE KEVCVSS 3.1HIGH 8.3
See all 15278 →

Sources