Executive Summary
Informations | |||
---|---|---|---|
Name | CVE-2022-49067 | First vendor Publication | 2025-02-26 |
Vendor | Cve | Last vendor Modification | 2025-02-26 |
Security-Database Scoring CVSS v3
Cvss vector : N/A | |||
---|---|---|---|
Overall CVSS Score | NA | ||
Base Score | NA | Environmental Score | NA |
impact SubScore | NA | Temporal Score | NA |
Exploitabality Sub Score | NA | ||
Calculate full CVSS 3.0 Vectors scores |
Security-Database Scoring CVSS v2
Cvss vector : | |||
---|---|---|---|
Cvss Base Score | N/A | Attack Range | N/A |
Cvss Impact Score | N/A | Attack Complexity | N/A |
Cvss Expoit Score | N/A | Authentication | N/A |
Calculate full CVSS 2.0 Vectors scores |
Detail
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: 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)! The code shows below, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start 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] |
Original Source
Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-49067 |
Sources (Detail)
Alert History
Date | Informations |
---|---|
2025-02-26 17:20:34 |
|