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.

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - powerpc64 ビット Book3E および 32 ビット mpe の virt_addr_valid() を修正します64 ビット Book3E における vmalloc 空間は、0x800000000000000 で開始します。__pa() の動作のために __pa(0x800000000000000) == 0、したがって virt_to_pfn(0x8000000000000000000) == 0、したがって virt_addr_valid(0x8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000可能性があります。実際には、有効な PFN でエイリアス化されたすべての vmalloc アドレスは、virt_addr_valid() から true を返します。これにより、Kefeng Wang 氏が以下の説明のように、強化された usercopy でバグが発生する可能性があります 64 ビット Book3E で ethtool eth0 を実行する際、バグが発生しましたusercopy
    SLUB ページではない SLUB オブジェクトからカーネルメモリ漏洩の試行が検出されましたか?!オフセット 0、サイズ 1048! mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 でのカーネルバグ信頼できない__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) データは vmalloc() によって割り当てられ、virt_addr_valid(ptr) が 64 ビット Book3E で真を返すため、パニックを引き起こします。コミット 4dd7554a6456powerpc/64__va と __pa アドレスの VIRTUAL_BUG_ON チェックを追加が行うように、64 ビットの virt_addr_valid() の PAGE_OFFSET 上の virt addr を必ず確認し、また virt が high_memory 未満であることを確認するための上限チェックも追加します。一方、32ビットの場合、PAGE_OFFSETはlowmemの開始の仮想アドレスであり、high_memoryは上限の低い仮想アドレスであり、チェックは32ビットに適しています。これは、コミット602946ec2f90に記載されている問題を修正しますpowerpcmax_mapnrを適切に設定も参照してください。32 ビットには、高メモリに関する類似の問題があります。これは、コミット 602946ec2f90 で修正されていますpowerpcmax_mapnr を適切に設定しますそのコミットは、highmem を破損するため、元に戻す必要があります。__pa() を簡単に修正できません。現在の挙動に依存するコードがあります。そのため、現時点では virt_addr_valid() に追加のチェックを追加しています。64 ビットの Book3S では、追加のチェックは必要ありません。virt_to_pfn() と pfn_valid() の組み合わせによって正しい結果が得られるはずですが、これらは無害です。 [mpe変更ログの詳細を追加します]CVE-2022-49067

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-987663 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    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]

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-989563 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    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]

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - powerpc修正 64 位元 Book3E 和 32 位元 mpe的 virt_addr_valid()在 64 位元 Book3E 上vmalloc 空間開始於 0x8000000000000000。由於 __pa() 的運作方式我們有 __pa(0x8000000000000000) == 0因此 virt_to_pfn(0x8000000000000000) == 0因此 virt_addr_valid(0x800000000000000) == true 哪個錯誤virt_addr_valid() 應該為 false vmalloc空格。實際上所有以有效 PFN 為別名的 vmalloc 位址都會從 virt_addr_valid() 傳回 true。這可造成強化的 usercopy 發生錯誤如下Kefeng Wang 所述在 64 位元 Book3E 上執行 ethtool eth0 時發生錯誤
    從非 SLUB 頁面中的 SLUB 物件偵測到核心記憶體洩漏嘗試？ (位移 0大小 1048) mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 的核心錯誤 (不可靠) __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)) 資料由 vmalloc() 配置virt_addr_valid(ptr) 將在 64 位元 Book3E 上傳回 true進而導致發生錯誤。如同提交 4dd7554a6456 (powerpc/64新增 __va 和 __pa 位址的 VIRTUA_BUG_ON 檢查)一樣確保 virt_addr 在 64 位元的 virt_addr_valid() 中高於 PAGE_OFFSET 的位置同時新增上限檢查以確保 virt 低於 high_memory。同時對於 32 位元PAGE_OFFSET 是 lowmem 的開頭虛擬位址high_memory 是上限 low 虛擬位址該檢查適用於 32 位元這將修正認可 602946ec2f90 中提及的問題 (powerpc正確設定 max_mapnr)也一樣。在 32 位元中存有一個與高記憶體相關的類似問題已在認可 602946ec2f90 中修正 (powerpc正確設定 max_mapnr)但該認可會中斷 highmem 且需要還原。我們無法輕易修正 __pa()我們有仰賴其目前行為的程式碼。因此現在將額外檢查新增至 virt_addr_valid()。若是 64 位元 Book3S則不需要額外檢查virt_to_pfn() 與 pfn_valid() 的組合應會產生正確的結果但這些作業並無害處。 [mpe新增其他變更記錄詳細資料] (CVE-2022-49067)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - powerpc修复 64 位 Book3E 和 32 位的 virt_addr_valid() mpe在 64 位 Book3E 上vmalloc 空间从 0x8000000000000000 开始。由于 __pa() 的工作方式我们有 __pa(0x8000000000000000) == 0 则 virt_to_pfn(0x8000000000000000) == 0 则 virt_addr_valid(0x8000000000000000) == true 哪项错误vloc 的 virt_maladdr_valid() 应为 false空间。实际上具有有效 PFN 的别名的所有 vmalloc 地址都将从 virt_addr_valid() 返回 true。这可导致强化的 usercopy 出现缺陷如 Kefeng Wang 所述在 64 位 Book3E 上运行 ethtool eth0 时发生缺陷usercopy
    尝试从不在 SLUB 页面中的 SLUB 对象检测到内核内存泄露尝试偏移 0大小 1048 mm/usercopy.c:99 的内核缺陷 ... usercopy_abort+0x64/0xa0不可靠 __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)) 通过 vmalloc() 分配数据virt_addr_valid(ptr) 将在 64 位 Book3E 上返回 true从而导致错误。提交 4dd7554a6456powerpc/64为 __va 和 __pa 地址添加 VIRTual_BUG_ON 检查在确保 64 位的 virt_addr_valid() 中 PAGE_OFFSET 上方的 virt 地址还添加了上限检查以确保 virt 低于 high_memory。同时对于 32 位PAGE_OFFSET 是 lowmem 的开头虚拟地址high_memory 是上限低虚拟地址该检查适用于 32 位这将修复 commit 602946ec2f90powerpc正确设置 max_mapnr 中提及的问题也一样。在 32 位中存在一个与高内存有关的类似问题已在提交 602946ec2f90powerpc正确设置 max_mapnr中修复但该提交破坏了 highmem并且需要恢复。不能轻松修复 __pa()我们拥有依赖其当前行为的代码。目前请将额外检查添加至 virt_addr_valid()。对于 64 位 Book3S 不需要额外检查virt_to_pfn() 和 pfn_valid() 的组合应该产生正确的结果但它们是无害的。 [mpe添加其他更改日志详细信息] (CVE-2022-49067)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
225357	Linux Distros Unpatched Vulnerability : CVE-2022-49067	Nessus	Misc.	2025/3/5	2025/9/30	medium
225357	Linux Distros のパッチ未適用の脆弱性: CVE-2022-49067	Nessus	Misc.	2025/3/5	2025/9/30	medium
270895	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987663)	Nessus	Unity Linux Local Security Checks	2025/10/21	2025/10/21	medium
273799	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-989563)	Nessus	Unity Linux Local Security Checks	2025/11/5	2025/11/5	medium
225357	Linux Distros 未修補的弱點：CVE-2022-49067	Nessus	Misc.	2025/3/5	2025/9/30	medium
225357	Linux Distros 未修补的漏洞：CVE-2022-49067	Nessus	Misc.	2025/3/5	2025/9/30	medium

检测

插件搜索

medium

medium

medium

medium

medium

medium