FKIE_CVE-2022-49067
Vulnerability from fkie_nvd - Published: 2025-02-26 07:00 - Updated: 2026-06-17 05:16
Severity
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]
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 5.18 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/powerpc/include/asm/page.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "deab81144d5a043f42804207fb76cfbd8a806978",
"status": "affected",
"version": "ffda09a9941c18d9f08d1176d55588d505f62912",
"versionType": "git"
},
{
"lessThan": "d36febbcd537fcc50284e8b89609632d0146529f",
"status": "affected",
"version": "ffda09a9941c18d9f08d1176d55588d505f62912",
"versionType": "git"
},
{
"lessThan": "fddb88bd266f4513abab7c36bca98935c9148a98",
"status": "affected",
"version": "ffda09a9941c18d9f08d1176d55588d505f62912",
"versionType": "git"
},
{
"lessThan": "a3727c25eacd7e437c4f560957fa3a376fe93e6b",
"status": "affected",
"version": "ffda09a9941c18d9f08d1176d55588d505f62912",
"versionType": "git"
},
{
"lessThan": "cbc065efcba000ad8f615f506ebe61b6d3c5145b",
"status": "affected",
"version": "ffda09a9941c18d9f08d1176d55588d505f62912",
"versionType": "git"
},
{
"lessThan": "ffa0b64e3be58519ae472ea29a1a1ad681e32f48",
"status": "affected",
"version": "ffda09a9941c18d9f08d1176d55588d505f62912",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/powerpc/include/asm/page.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.4"
},
{
"lessThan": "4.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.190",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.111",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.34",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.16.*",
"status": "unaffected",
"version": "5.16.20",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.17.*",
"status": "unaffected",
"version": "5.17.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "07007AB8-22EB-4618-8183-08F71279EB4E",
"versionEndExcluding": "5.4.190",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "96258501-7BCE-4C55-8A38-8AC9D327626D",
"versionEndExcluding": "5.10.111",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D25878D3-7761-4E9F-8919-E92CD53896E0",
"versionEndExcluding": "5.15.34",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "ABBBA66E-0244-4621-966B-9790AF1EEB00",
"versionEndExcluding": "5.16.20",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AE420AC7-1E59-4398-B84F-71F4B4337762",
"versionEndExcluding": "5.17.3",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:5.18:rc1:*:*:*:*:*:*",
"matchCriteriaId": "6AD94161-84BB-42E6-9882-4FC0C42E9FC1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc: Fix virt_addr_valid() for 64-bit Book3E \u0026 32-bit\n\nmpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.\n\nBecause of the way __pa() works we have:\n __pa(0x8000000000000000) == 0, and therefore\n virt_to_pfn(0x8000000000000000) == 0, and therefore\n virt_addr_valid(0x8000000000000000) == true\n\nWhich is wrong, virt_addr_valid() should be false for vmalloc space.\nIn fact all vmalloc addresses that alias with a valid PFN will return\ntrue from virt_addr_valid(). That can cause bugs with hardened usercopy\nas described below by Kefeng Wang:\n\n When running ethtool eth0 on 64-bit Book3E, a BUG occurred:\n\n usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!\n kernel BUG at mm/usercopy.c:99\n ...\n usercopy_abort+0x64/0xa0 (unreliable)\n __check_heap_object+0x168/0x190\n __check_object_size+0x1a0/0x200\n dev_ethtool+0x2494/0x2b20\n dev_ioctl+0x5d0/0x770\n sock_do_ioctl+0xf0/0x1d0\n sock_ioctl+0x3ec/0x5a0\n __se_sys_ioctl+0xf0/0x160\n system_call_exception+0xfc/0x1f0\n system_call_common+0xf8/0x200\n\n The code shows below,\n\n data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));\n copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))\n\n The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true\n on 64-bit Book3E, which leads to the panic.\n\n As commit 4dd7554a6456 (\"powerpc/64: Add VIRTUAL_BUG_ON checks for __va\n and __pa addresses\") does, make sure the virt addr above PAGE_OFFSET in\n the virt_addr_valid() for 64-bit, also add upper limit check to make\n sure the virt is below high_memory.\n\n Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start\n of lowmem, high_memory is the upper low virtual address, the check is\n suitable for 32-bit, this will fix the issue mentioned in commit\n 602946ec2f90 (\"powerpc: Set max_mapnr correctly\") too.\n\nOn 32-bit there is a similar problem with high memory, that was fixed in\ncommit 602946ec2f90 (\"powerpc: Set max_mapnr correctly\"), but that\ncommit breaks highmem and needs to be reverted.\n\nWe can\u0027t easily fix __pa(), we have code that relies on its current\nbehaviour. So for now add extra checks to virt_addr_valid().\n\nFor 64-bit Book3S the extra checks are not necessary, the combination of\nvirt_to_pfn() and pfn_valid() should yield the correct result, but they\nare harmless.\n\n[mpe: Add additional change log detail]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc: Arreglar virt_addr_valid() para Book3E de 64 bits y mpe de 32 bits: En Book3E de 64 bits, el espacio vmalloc comienza en 0x8000000000000000. Debido a la forma en que funciona __pa() tenemos: __pa(0x8000000000000000) == 0, y por lo tanto virt_to_pfn(0x8000000000000000) == 0, y por lo tanto virt_addr_valid(0x8000000000000000) == true Lo cual es incorrecto, virt_addr_valid() deber\u00eda ser falso para el espacio vmalloc. De hecho, todas las direcciones vmalloc que tengan un alias con un PFN v\u00e1lido devolver\u00e1n verdadero desde virt_addr_valid(). Esto puede causar errores con usercopy reforzado como lo describe a continuaci\u00f3n Kefeng Wang: Al ejecutar ethtool eth0 en Book3E de 64 bits, ocurri\u00f3 un ERROR: usercopy: \u00a1Intento de exposici\u00f3n de memoria del kernel detectado desde un objeto SLUB que no est\u00e1 en la p\u00e1gina SLUB! (desplazamiento 0, tama\u00f1o 1048). ERROR del kernel en mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 (no confiable) __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 El c\u00f3digo se muestra a continuaci\u00f3n, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) Los datos se asignan mediante vmalloc(), virt_addr_valid(ptr) devolver\u00e1 verdadero en Book3E de 64 bits, lo que genera el p\u00e1nico. Como lo hace el commit 4dd7554a6456 (\"powerpc/64: Agregar comprobaciones VIRTUAL_BUG_ON para direcciones __va y __pa\"), aseg\u00farese de que la direcci\u00f3n virt sea superior a PAGE_OFFSET en virt_addr_valid() para 64 bits, y agregue tambi\u00e9n una comprobaci\u00f3n de l\u00edmite superior para asegurarse de que la direcci\u00f3n virt est\u00e9 por debajo de high_memory. Mientras tanto, para 32 bits PAGE_OFFSET es la direcci\u00f3n virtual del inicio de lowmem, high_memory es la direcci\u00f3n virtual baja superior, la comprobaci\u00f3n es adecuada para 32 bits, esto solucionar\u00e1 tambi\u00e9n el problema mencionado en el commit 602946ec2f90 (\"powerpc: Set max_mapnr properly\"). En 32 bits hay un problema similar con la memoria alta, que se solucion\u00f3 en el commit 602946ec2f90 (\"powerpc: Set max_mapnr properly\"), pero ese commit rompe highmem y necesita ser revertido. No podemos arreglar f\u00e1cilmente __pa(), tenemos c\u00f3digo que depende de su comportamiento actual. As\u00ed que por ahora agregue comprobaciones adicionales a virt_addr_valid(). Para Book3S de 64 bits las comprobaciones adicionales no son necesarias, la combinaci\u00f3n de virt_to_pfn() y pfn_valid() deber\u00eda producir el resultado correcto, pero son inofensivas. [mpe: Agregar detalles adicionales del registro de cambios]"
}
],
"id": "CVE-2022-49067",
"lastModified": "2026-06-17T05:16:59.383",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-02-26T07:00:43.927",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/deab81144d5a043f42804207fb76cfbd8a806978"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fddb88bd266f4513abab7c36bca98935c9148a98"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ffa0b64e3be58519ae472ea29a1a1ad681e32f48"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…