CVE-2022-49067

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc: Fix virt_addr_valid() for 64-bit Book3E &amp; 32-bit<br /> <br /> mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.<br /> <br /> Because of the way __pa() works we have:<br /> __pa(0x8000000000000000) == 0, and therefore<br /> virt_to_pfn(0x8000000000000000) == 0, and therefore<br /> virt_addr_valid(0x8000000000000000) == true<br /> <br /> Which is wrong, virt_addr_valid() should be false for vmalloc space.<br /> In fact all vmalloc addresses that alias with a valid PFN will return<br /> true from virt_addr_valid(). That can cause bugs with hardened usercopy<br /> as described below by Kefeng Wang:<br /> <br /> When running ethtool eth0 on 64-bit Book3E, a BUG occurred:<br /> <br /> usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!<br /> kernel BUG at mm/usercopy.c:99<br /> ...<br /> usercopy_abort+0x64/0xa0 (unreliable)<br /> __check_heap_object+0x168/0x190<br /> __check_object_size+0x1a0/0x200<br /> dev_ethtool+0x2494/0x2b20<br /> dev_ioctl+0x5d0/0x770<br /> sock_do_ioctl+0xf0/0x1d0<br /> sock_ioctl+0x3ec/0x5a0<br /> __se_sys_ioctl+0xf0/0x160<br /> system_call_exception+0xfc/0x1f0<br /> system_call_common+0xf8/0x200<br /> <br /> The code shows below,<br /> <br /> data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));<br /> copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))<br /> <br /> The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true<br /> on 64-bit Book3E, which leads to the panic.<br /> <br /> As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va<br /> and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in<br /> the virt_addr_valid() for 64-bit, also add upper limit check to make<br /> sure the virt is below high_memory.<br /> <br /> Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start<br /> of lowmem, high_memory is the upper low virtual address, the check is<br /> suitable for 32-bit, this will fix the issue mentioned in commit<br /> 602946ec2f90 ("powerpc: Set max_mapnr correctly") too.<br /> <br /> On 32-bit there is a similar problem with high memory, that was fixed in<br /> commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that<br /> commit breaks highmem and needs to be reverted.<br /> <br /> We can&amp;#39;t easily fix __pa(), we have code that relies on its current<br /> behaviour. So for now add extra checks to virt_addr_valid().<br /> <br /> For 64-bit Book3S the extra checks are not necessary, the combination of<br /> virt_to_pfn() and pfn_valid() should yield the correct result, but they<br /> are harmless.<br /> <br /> [mpe: Add additional change log detail]