CVE-2022-49067

Source
https://nvd.nist.gov/vuln/detail/CVE-2022-49067
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49067.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2022-49067
Related
Published
2025-02-26T07:00:43Z
Modified
2025-02-26T19:02:49.016661Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

powerpc: Fix virtaddrvalid() 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 virttopfn(0x8000000000000000) == 0, and therefore virtaddrvalid(0x8000000000000000) == true

Which is wrong, virtaddrvalid() should be false for vmalloc space. In fact all vmalloc addresses that alias with a valid PFN will return true from virtaddrvalid(). 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(), virtaddrvalid(ptr) will return true on 64-bit Book3E, which leads to the panic.

As commit 4dd7554a6456 ("powerpc/64: Add VIRTUALBUGON checks for _va and _pa addresses") does, make sure the virt addr above PAGEOFFSET in the virtaddrvalid() for 64-bit, also add upper limit check to make sure the virt is below highmemory.

Meanwhile, for 32-bit PAGEOFFSET is the virtual address of the start of lowmem, highmemory 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 virtaddr_valid().

For 64-bit Book3S the extra checks are not necessary, the combination of virttopfn() and pfn_valid() should yield the correct result, but they are harmless.

[mpe: Add additional change log detail]

References

Affected packages

Debian:11 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.10.113-1

Affected versions

5.*

5.10.46-4
5.10.46-5
5.10.70-1~bpo10+1
5.10.70-1
5.10.84-1
5.10.92-1~bpo10+1
5.10.92-1
5.10.92-2
5.10.103-1~bpo10+1
5.10.103-1
5.10.106-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Debian:12 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.17.3-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.17.3-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}