DEBIAN-CVE-2022-49067

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 ... usercopyabort+0x64/0xa0 (unreliable) _checkheapobject+0x168/0x190 _checkobjectsize+0x1a0/0x200 devethtool+0x2494/0x2b20 devioctl+0x5d0/0x770 sockdoioctl+0xf0/0x1d0 sockioctl+0x3ec/0x5a0 _sesysioctl+0xf0/0x160 systemcallexception+0xfc/0x1f0 systemcallcommon+0xf8/0x200 The code shows below, data = vzalloc(arraysize(gstrings.len, ETHGSTRINGLEN)); copytouser(useraddr, data, gstrings.len * ETHGSTRINGLEN)) 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 maxmapnr correctly") too. On 32-bit there is a similar problem with high memory, that was fixed in commit 602946ec2f90 ("powerpc: Set maxmapnr 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 virtaddrvalid(). For 64-bit Book3S the extra checks are not necessary, the combination of virttopfn() and pfnvalid() should yield the correct result, but they are harmless. [mpe: Add additional change log detail]