The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - powerpc: Fix virt_addr_valid() 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     virt_to_pfn(0x8000000000000000) == 0, and therefore virt_addr_valid(0x8000000000000000) == true Which is     wrong, virt_addr_valid() should be false for vmalloc space. In fact all vmalloc addresses that alias with     a valid PFN will return true from virt_addr_valid(). 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(), virt_addr_valid(ptr) will return true on 64-bit Book3E, which leads to the panic. As commit     4dd7554a6456 (powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses) does, make sure the     virt addr above PAGE_OFFSET in the virt_addr_valid() for 64-bit, also add upper limit check to make sure     the virt is below high_memory. Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start of     lowmem, high_memory 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 virt_addr_valid(). For 64-bit     Book3S the extra checks are not necessary, the combination of virt_to_pfn() and pfn_valid() should yield     the correct result, but they are harmless. [mpe: Add additional change log detail] (CVE-2022-49067)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2022-49067

medium Nessus Plugin ID 225357

Version 1.11

Version 1.10

Version 1.9

Version 1.7

Version 1.3

Version 1.1

Version 1.11 Jun 30, 2026, 12:42 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202606300042
Version 1.10 Jun 28, 2026, 2:24 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202606280224
Version 1.9 Jun 17, 2026, 2:25 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202606171425
Version 1.7 May 15, 2026, 12:01 PM CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:U/RL:U/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:U/RL:U/RC:C") Detection (updated detection logic) Plugin metadata Plugin Feed: 202605151201
Version 1.3 Aug 21, 2025, 7:41 AM CVSS metrics ("Cvssv4 score" set to 0.0) CVSSv2 severity (based on None, severity decreased from "High" to "Low") Detection (updated detection logic) Plugin metadata Plugin Feed: 202508210741
Version 1.1 Mar 5, 2025, 4:35 PM New Plugin Feed: 202503051635