{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2022-49067", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-02-26T01:49:39.244Z", "datePublished": "2025-02-26T01:54:34.862Z", "dateUpdated": "2025-05-04T08:29:01.661Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2025-05-04T08:29:01.661Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc: Fix virt_addr_valid() for 64-bit Book3E & 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't 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]"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/powerpc/include/asm/page.h"], "versions": [{"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "deab81144d5a043f42804207fb76cfbd8a806978", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "d36febbcd537fcc50284e8b89609632d0146529f", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "fddb88bd266f4513abab7c36bca98935c9148a98", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "a3727c25eacd7e437c4f560957fa3a376fe93e6b", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "cbc065efcba000ad8f615f506ebe61b6d3c5145b", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "ffa0b64e3be58519ae472ea29a1a1ad681e32f48", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/powerpc/include/asm/page.h"], "versions": [{"version": "5.4.190", "lessThanOrEqual": "5.4.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.10.111", "lessThanOrEqual": "5.10.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.15.34", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.16.20", "lessThanOrEqual": "5.16.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.17.3", "lessThanOrEqual": "5.17.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.18", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionEndExcluding": "5.4.190"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionEndExcluding": "5.10.111"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionEndExcluding": "5.15.34"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionEndExcluding": "5.16.20"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionEndExcluding": "5.17.3"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionEndExcluding": "5.18"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/deab81144d5a043f42804207fb76cfbd8a806978"}, {"url": "https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f"}, {"url": "https://git.kernel.org/stable/c/fddb88bd266f4513abab7c36bca98935c9148a98"}, {"url": "https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b"}, {"url": "https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b"}, {"url": "https://git.kernel.org/stable/c/ffa0b64e3be58519ae472ea29a1a1ad681e32f48"}], "title": "powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit", "x_generator": {"engine": "bippy-1.2.0"}}}}

{}

{"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 & 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't 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]"}], "id": "CVE-2022-49067", "lastModified": "2025-02-26T07:00:43.927", "metrics": {}, "published": "2025-02-26T07:00:43.927", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/deab81144d5a043f42804207fb76cfbd8a806978"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/fddb88bd266f4513abab7c36bca98935c9148a98"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/ffa0b64e3be58519ae472ea29a1a1ad681e32f48"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Received"}

{"bugzilla": {"description": "kernel: powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit", "id": "2348129", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2348129"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\npowerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit\nmpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.\nBecause of the way __pa() works we have:\n__pa(0x8000000000000000) == 0, and therefore\nvirt_to_pfn(0x8000000000000000) == 0, and therefore\nvirt_addr_valid(0x8000000000000000) == true\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:\nWhen running ethtool eth0 on 64-bit Book3E, a BUG occurred:\nusercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!\nkernel BUG at mm/usercopy.c:99\n...\nusercopy_abort+0x64/0xa0 (unreliable)\n__check_heap_object+0x168/0x190\n__check_object_size+0x1a0/0x200\ndev_ethtool+0x2494/0x2b20\ndev_ioctl+0x5d0/0x770\nsock_do_ioctl+0xf0/0x1d0\nsock_ioctl+0x3ec/0x5a0\n__se_sys_ioctl+0xf0/0x160\nsystem_call_exception+0xfc/0x1f0\nsystem_call_common+0xf8/0x200\nThe code shows below,\ndata = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));\ncopy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))\nThe data is alloced by vmalloc(), virt_addr_valid(ptr) will return true\non 64-bit Book3E, which leads to the panic.\nAs commit 4dd7554a6456 (\"powerpc/64: Add VIRTUAL_BUG_ON checks for __va\nand __pa addresses\") does, make sure the virt addr above PAGE_OFFSET in\nthe virt_addr_valid() for 64-bit, also add upper limit check to make\nsure the virt is below high_memory.\nMeanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start\nof lowmem, high_memory is the upper low virtual address, the check is\nsuitable for 32-bit, this will fix the issue mentioned in commit\n602946ec2f90 (\"powerpc: Set max_mapnr correctly\") too.\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.\nWe can't easily fix __pa(), we have code that relies on its current\nbehaviour. So for now add extra checks to virt_addr_valid().\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[mpe: Add additional change log detail]"], "name": "CVE-2022-49067", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2025-02-26T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2022-49067\nhttps://nvd.nist.gov/vuln/detail/CVE-2022-49067\nhttps://lore.kernel.org/linux-cve-announce/2025022654-CVE-2022-49067-94d7@gregkh/T"], "threat_severity": "Low"}