{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2022-49067 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-49067 is a medium-severity memory corruption vulnerability in Linux kernel, published on 26 Feb 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2022-49067 and fix it if it is affected.\n\nWhat it is: CVE-2022-49067 is a medium-severity memory corruption vulnerability in Linux kernel, published on 26 Feb 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2022-49067 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2022-49067/ (Markdown: https://insights.sbomify.com/CVE-2022-49067/index.md)","id":"CVE-2022-49067","markdown":"https://insights.sbomify.com/CVE-2022-49067/index.md","name":"CVE-2022-49067","record":{"aliases":["DEBIAN-CVE-2022-49067","GHSA-3vm4-73fj-2j43","UBUNTU-CVE-2022-49067"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A flaw in the Linux kernel's powerpc architecture allows incorrect virtual address validation, leading to kernel panics and denial of service.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[],"description":"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'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]","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"powerpc: Fix virt_addr_valid() for 64-bit Book3E \u0026 32-bit","id":"CVE-2022-49067","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"memory_corruption","year":"2022"},"n_packages":0,"n_references":6,"next":{"headline":"btrfs: release correct delalloc amount in direct IO write path","id":"CVE-2022-49068"},"packages":[],"prev":{"headline":"veth: Ensure eth header is in skb's linear part","id":"CVE-2022-49066"},"products":["Linux"],"published":"2025-02-26","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A flaw in the Linux kernel's powerpc architecture allows incorrect virtual address validation, leading to kernel panics and denial of service.","url":"https://insights.sbomify.com/CVE-2022-49067/"}