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

  - ACPI： 匯流排：引入 acpi_bus_get_primary_device（） 用於取得第一個實體裝置的函式，其中指定的 ACPI 裝置是 ACPI 配套裝置，acpi_get_first_physical_node（） 可能會傳回過時的裝置指標 （主要是理論上），因為 acpi_unbind_one（） 可能會在 acpi_get_first_physical_node（） 中刪除 ACPI 裝置的physical_node_lock之後，在傳回之前整體執行。在實體裝置的指標傳回給呼叫端之前，可能會卸除實體裝置的最後一個參考。
    如果發生這種情況，並且 acpi_get_first_physical_node（） 調用方在從它獲得的指標上調用 get_device（），這是由其大多數調用方完成的，則會發生釋放後使用。若要準備解決此問題，請引進新功能，以取得與指定 ACPI 相關聯的第一個實體裝置 （主要實體裝置） ，該裝置也會在傳回指標之前參考計數有問題的裝置。讓該新功能和 acpi_get_first_physical_node（） 共用實體節點清單查詢程式碼。沒有故意的功能影響。（CVE-2026-93251）

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

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

  - ACPI：bus：引入 acpi_bus_get_primary_device（） 用于获取给定 ACPI 作为 ACPI 伙伴的第一个物理设备的函数 acpi_get_first_physical_node（） 可能会返回过时的设备指针（主要是理论上），因为 acpi_unbind_one（） 可能会在 acpi_get_first_physical_node（） 中丢弃 ACPI 设备的physical_node_lock之后和返回之前作为一个整体运行。然后，在将指向该物理设备的指针返回给调用程序之前，可能会丢弃对该物理设备的最后引用。
    如果发生这种情况，并且 acpi_get_first_physical_node（） 调用程序对从其获取的指针调用 get_device（），这将由其大多数调用程序完成，则将发生释放后使用。若要准备解决此问题，请引入一个新功能，用于获取与给定 ACPI 设备关联的第一个物理设备 （主要物理设备） ，该设备还将在返回指针之前引用相关设备计数。使该新函数和 acpi_get_first_physical_node（） 共享物理节点列表查找代码。无意影响功能。（CVE-2026-93251）

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

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

  - ACPI:bus:acpi_bus_get_primary_device() を導入 指定された ACPI デバイスが ACPI コンパニオンである最初の物理デバイスを取得するために使用される関数 acpi_get_first_physical_node() は、古いデバイスポインターを(ほとんど理論上)返すことがあります。これは、acpi_unbind_one() が acpi_get_first_physical_node() で ACPI デバイスのphysical_node_lockを削除した後、戻ってくる前に全体として実行される可能性があるためです。物理デバイスへの最後の参照は、そのデバイスへのポインターが呼び出し側に返される前にドロップされる可能性があります。
    これが発生し、acpi_get_first_physical_node()呼び出し元がそこから取得したポインターでget_device()を呼び出すと(大多数の呼び出し元によって行われます)、メモリ解放後使用(Use After Free)が発生します。この問題に対処する準備をするために、特定の ACPI デバイスに関連付けられた最初の物理デバイス (プライマリ物理デバイス) を取得するための新しい関数を導入します。このデバイスは、ポインターを返す前に問題のデバイスをカウントすることも参照します。その新しい関数と acpi_get_first_physical_node() が物理ノードリストルックアップコードを共有するようにします。意図的な機能への影響はありません。(CVE-2026-93251)

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

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1792243434 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns:
    hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >=     DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of     port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
    because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array     overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function     returns. (CVE-2021-47548)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a suspicious RCU usage     warning I received the following warning while running cthon against an ontap server running pNFS: [     57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523]     6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525]     net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that     might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks     held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted     6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU     Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [     57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556]     rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596]     rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621]     ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646]     rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ?
    __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [     57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728]     ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754]     nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [     57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files     e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4     c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs     6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ?
    __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891]     nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913]     do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921]     filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930]     nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947]     nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969]
    __se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [     57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982]     RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00     90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83     ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX:
    0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [     57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP:
    00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated---     (CVE-2023-52623)

  - In the Linux kernel, the following vulnerability has been resolved: dm: call the resume method on internal     suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is     caused by the fact that the postsuspend and resume methods were not paired correctly; there were two     consecutive calls to the origin_postsuspend function. The second call attempts to remove the hash_list     entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it     calls the preresume and resume methods of the table's targets. If a preresume method of some target fails,     we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return     errors. We can't return success, because then the resume and postsuspend methods would not be paired     correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools,     but it won't cause a kernel crash. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56!     invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware     name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP:
    0010:__list_del_entry_valid_or_report+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX:
    000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0     RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10:
    0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0     R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010     DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0     Call Trace: <TASK> ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ?     do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ?
    __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0     [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot]     dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0     [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10     [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0     entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]---     (CVE-2024-26880)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: flush pending     destroy work before exit_net release Similar to 2c9f0293280e (netfilter: nf_tables: flush pending destroy     work before netlink notifier) to address a race between exit_net and the destroy workqueue. The trace     below shows an element to be released via destroy workqueue while exit_net path (triggered via module     removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-     use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at     addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not     tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [     1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014]     print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590     [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ?     nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312]     nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ?
    __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [     1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ?
    __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10     [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690]     ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK> [ 1360.548719] Allocated by task 192061: [ 1360.548726]     kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750]
    __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771]     nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [     1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [     1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953]
    ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120     [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 1360.548994] Freed by task 192222: [     1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019]     kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036]
    __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0     [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221]     ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236]     unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254]     nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [     1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d (gdb) list
    *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349     list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list);
    11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354     list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356     nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat
    ---truncated--- (CVE-2024-35899)

  - In the Linux kernel, the following vulnerability has been resolved: drm/client: Fully protect modes[] with     dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which     are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time     we use it the elements may already be pointing to freed/reused memory. (CVE-2024-35950)

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

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

  - ACPI: bus: Introduce acpi_bus_get_primary_device() The function used for obtaining the first physical     device for which the given ACPI one is the ACPI companion, acpi_get_first_physical_node(), may return a     stale device pointer (mostly in theory) because acpi_unbind_one() may run as a whole after dropping the     ACPI device's physical_node_lock in acpi_get_first_physical_node() and before it returns. The last     reference to the physical device may be dropped then before the pointer to it is returned to the caller.
    If that happens and the acpi_get_first_physical_node() caller invokes get_device() on the pointer obtained     from it, which is done by the majority of its callers, a use-after-free will occur. To prepare for     addressing this problem, introduce a new function for getting the first physical device associated with     the given ACPI one (the primary physical device) that will also reference count the device in question     before returning a pointer to it. Make that new function and acpi_get_first_physical_node() share the     physical node list lookup code. No intentional functional impact. (CVE-2026-93251)

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

ID	Name	Product	Family	Published	Updated	Severity
349831	Linux Distros 未修補弱點：CVE-2026-93251	Nessus	Misc.	9/24/2026	9/25/2026	medium
349831	Linux Distros 未修补的漏洞：CVE-2026-93251	Nessus	Misc.	9/24/2026	9/25/2026	medium
349831	Linux Distros のパッチ未適用の脆弱性: CVE-2026-93251	Nessus	Misc.	9/24/2026	9/25/2026	medium
366778	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1792243434)	Nessus	Alma Linux Local Security Checks	10/17/2026	10/17/2026	medium
349831	Linux Distros Unpatched Vulnerability : CVE-2026-93251	Nessus	Misc.	9/24/2026	9/25/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium

medium