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

  - arm64mte如果未清除或還原任何標籤則避免設定 PG_mte_tagg。在提交 69e3b846d8a7 之前 (arm64mte針對 PTE 未標記的頁面同步標籤)僅針對 pte_tagged() 項目 (與 PROT_MTE 對應的項目) 呼叫 mte_sync_tags() 。因此mte_sync_tags() 可安全地使用 test_and_set_bit(PG_mte_tugged, &page->flags)而不會在未標記的頁面上意外設定 PG_mte_tagged。上述認可是必要的因為來賓可在沒有任何控制項的情況下啟用 MTE第 2 階段對應也不會在 VMM 中進行 PROT_MTE 對應。不過副作用是任何具有 PTE 看起來像交換 (或移轉) 的頁面都會自動設定 PG_mte_tugged。即使標籤是由 KASAN 所擁有後續的頁面複本 (例如移轉) 也會將標籤複製到目的地頁面。此問題已由認可 e5b8d9218951 中引入的 page_kasan_tag_reset() 呼叫遮罩 (arm64mte重設 page->flags 中的頁面標籤)。還原此提交時 (20794545c146)KASAN 會開始報告存取錯誤這是因為頁面中的覆寫標籤不符合原始 page->flags (CONFIG_KASAN_HW_TAGS=y) 錯誤
    KASANcopy_page+0x10/0xd0 arch/arm64/lib/copy_page.S:26 中的無效存取由工作 syz-executor.1/2218 在 addr f5ff000017f2e000 讀取 指標標籤[f5]、記憶體標籤[f2]將 PG_mte_tagg 位元設定從 mte_sync_tags() 修正為清除 (mte_sync_page_tags()) 或還原 (mte_restore_tags()) 標記的實際位置。 (CVE-2022-50675)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1783362244 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace.
    Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return) (CVE-2022-49308)

  - 已解決 Linux 核心中的下列弱點：tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade.
    Commit 28438794aba4 (modpost: fix section mismatch check for exported init/exit sections) fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost:
    vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable
    __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. (CVE-2022-49675)

  - 已解決 Linux 核心中的下列弱點：ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. (CVE-2022-49731)

  - 已解決 Linux 核心中的下列弱點：bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm ip, pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:
    [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49812)

  - 已解決 Linux 核心中的下列弱點：capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |--
    *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] (CVE-2022-49890)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
170458	Amazon Linux 2：核心， --advisory ALAS2KERNEL-5。15-2023-012（ALASKERNEL-5。15-2023-012	Nessus	Amazon Linux Local Security Checks	2023/1/24	2026/6/4	high
277948	Linux Distros 未修補的弱點：CVE-2022-50675	Nessus	Misc.	2025/12/9	2026/9/30	medium
360687	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1783362244）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high

偵測

搜尋 Plugin

high

medium

high