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

  - nvdimm:pmem:データが書き込まれる前に PREFLUSH を保持します pmem_submit_bio() によりREQ_PREFLUSHエラーが記録されますが、bio データのコピーが続いて、後で REQ_FUA フラッシュの成功によりエラーを上書きする可能性があります。これにより、プレフラッシュが失敗した後にデータ書き込みが実行され、順序付けバリアが失敗しても bio を正常に完了できます。bio データに触れる前に REQ_PREFLUSH フラッシュを同期的に実行し、失敗した場合はフラッシュエラーで bio を完了させます。REQ_FUA に対して非同期フラッシュチェーンを維持します。この時点でデータコピーは完了しており、親 bio は、連鎖的にフラッシュされた bio を待機できます。 (CVE-2026-98161)

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

AlmaLinux 9.2 ホストには、TuxCare ALMALINUX9.2:CLSA-2026:1791741836アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: vhost: fix hung thread due to erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at:
    https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
    (CVE-2022-48862)

  - Linux カーネルでは、以下の脆弱性が解決されています: net: hns3: add vlan list lock to protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in vf VLAN list as false. If the periodicity task is freeing the same node, it may cause use after free error. This patch adds a vlan list lock to protect the vlan list. (CVE-2022-49182)

  - Linux カーネルでは、以下の脆弱性が解決されています: perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF:
    supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60
    __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu. (CVE-2022-49781)

  - Linux カーネルでは、以下の脆弱性が解決されています: blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt and iocost, but not so for iolatency as it gets initialized before add_disk() is called. It is desirable to lazy-init rq_qos policies because they are optional features and add to hot path overhead once initialized - each IO has to walk all the registered rq_qos policies. So, we want to switch iolatency to lazy init too. However, that's a bigger change. As a fix for the immediate problem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk(). This is safe because duplicate calls to rq_qos_exit() become noop's. (CVE-2022-50550)

  - Linux カーネルでは、以下の脆弱性が解決されています: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations. (CVE-2024-26747)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

リモートのDebian 13ホストには、dsa-6568アドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    - ------------------------------------------------------------------------- Debianセキュリティアドバイザリ DSA-6568-1 security@debian.org https://www.debian.org/security/Salvatore Bonaccorso 2026 年 10 月 16 日 https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    パッケージ:linux CVE ID: CVE-2025-38204 CVE-2025-40158 CVE-2026-52988 CVE-2026-72315 CVE-2026-72463 CVE-2026-74347 CVE-2026-80935 CVE-2026-80937 CVE-2026-80939 CVE-2026-80980 CVE-2026-81016 CVE-2026-89437 CVE-2026-89441 CVE-2026-89445 CVE-2026-89452 CVE-2026-89467 CVE-2026-89500 CVE-2026-89503 CVE-2026-89520 CVE-2026-89527 CVE-2026-89633 CVE-2026-89638 CVE-2026-89766 CVE-2026-89795 CVE-2026-89797 CVE-2026-89806 CVE-2026-89827 CVE-2026-89832 CVE-2026-89837 CVE-2026-89838 CVE-2026-89840 CVE-2026-89859 CVE-2026-89868 CVE-2026-89912 CVE-2026-89921 CVE-2026-89956 CVE-2026-89971 CVE-2026-89972 CVE-2026-89996 CVE-2026-90002 CVE-2026-90013 CVE-2026-90016 CVE-2026-90023 CVE-2026-90029 CVE-2026-90030 CVE-2026-90146 CVE-2026-93179 CVE-2026-93196 CVE-2026-93199 CVE-2026-93200 CVE-2026-93231 CVE-2026-93243 CVE-2026-93244 CVE-2026-93285 CVE-2026-97527 CVE-2026-97528 CVE-2026-97529 CVE-2026-97530 CVE-2026-97531 CVE-2026-97532 CVE-2026-97534 CVE-2026-97535 CVE-2026-97536 CVE-2026-97537 CVE-2026-97549 CVE-2026-97558 CVE-2026-97559 CVE-2026-97566 CVE-2026-97567 CVE-2026-97571 CVE-2026-97574 CVE-2026-97594 CVE-2026-97597 CVE-2026-97603 CVE-2026-97609 CVE-2026-97615 CVE-2026-97618 CVE-2026-97619 CVE-2026-97620 CVE-2026-97901 CVE-2026-97906 CVE-2026-97918 CVE-2026-97919 CVE-2026-97933 CVE-2026-97934 CVE-2026-97935 CVE-2026-97938 CVE-2026-97939 CVE-2026-97949 CVE-2026-97950 CVE-2026-98101 CVE-2026-98161 CVE-2026-98167 CVE-2026-98168 CVE-2026-98169 CVE-2026-98170 CVE-2026-98171 CVE-2026-98172 CVE-2026-98173 CVE-2026-98174 CVE-2026-98175 CVE-2026-98179 CVE-2026-98181 CVE-2026-98182 CVE-2026-98184 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187 CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191 CVE-2026-98192 CVE-2026-98193 CVE-2026-98194 CVE-2026-98195 CVE-2026-98196 CVE-2026-98197 CVE-2026-98198 CVE-2026-98199 CVE-2026-98200 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203 CVE-2026-98204 CVE-2026-98205 CVE-2026-98206 CVE-2026-98207 CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98211 CVE-2026-98212 CVE-2026-98213 CVE-2026-98214 CVE-2026-98215 CVE-2026-98216 CVE-2026-98217 CVE-2026-98218 CVE-2026-98221 CVE-2026-98222 CVE-2026-98227 CVE-2026-98229 CVE-2026-98230 CVE-2026-98231 CVE-2026-98232 CVE-2026-98233 CVE-2026-98234 CVE-2026-98235 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238 CVE-2026-98239 CVE-2026-98241 CVE-2026-98245 CVE-2026-98246 CVE-2026-98247 CVE-2026-98248 CVE-2026-98249 CVE-2026-98251 CVE-2026-98252 CVE-2026-98253 CVE-2026-98254 CVE-2026-98255 CVE-2026-98257 CVE-2026-98260 CVE-2026-98261 CVE-2026-98262 CVE-2026-98263 CVE-2026-98264 CVE-2026-98265 CVE-2026-98266 CVE-2026-98267 CVE-2026-98269 CVE-2026-98270 CVE-2026-98271 CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282 CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98291 CVE-2026-98293 CVE-2026-98295 CVE-2026-98297 CVE-2026-98298 CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302 CVE-2026-98303 CVE-2026-98306 CVE-2026-98307 CVE-2026-98308 CVE-2026-98309 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314 CVE-2026-98316 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322 CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98327 CVE-2026-98328 CVE-2026-98329 CVE-2026-98331 CVE-2026-98334 CVE-2026-98335 CVE-2026-98336 CVE-2026-98337 CVE-2026-98339 CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344 CVE-2026-98345 CVE-2026-98346 CVE-2026-98347 CVE-2026-98348 CVE-2026-98349 CVE-2026-98351 CVE-2026-98352 CVE-2026-98354 CVE-2026-98357 CVE-2026-98358 CVE-2026-98359 CVE-2026-98360 CVE-2026-98362 CVE-2026-98363 CVE-2026-98365 CVE-2026-98366 CVE-2026-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370 CVE-2026-98373 CVE-2026-98374 CVE-2026-98375 CVE-2026-98377 CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381 CVE-2026-98382 CVE-2026-98383 CVE-2026-98384 CVE-2026-98386 CVE-2026-98403 CVE-2026-98406 CVE-2026-98407 CVE-2026-98409 CVE-2026-98410 CVE-2026-98411 CVE-2026-98412 CVE-2026-98413 CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421 CVE-2026-98422 CVE-2026-98423 CVE-2026-98425 CVE-2026-98426 CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432 CVE-2026-99999 Debianバグ:1149499 1149564 1150891

    Linux カーネルに、権限昇格、サービス拒否、または情報漏洩を引き起こす可能性がある、複数の脆弱性が発見されました。

    安定版 (stable) ディストリビューション (trixie) では、これらの問題はバージョン 6.12.113-1 で修正されています。

    お使いの linux パッケージをアップグレードすることを推奨します。

    linux の詳細なセキュリティステータスについては、そのセキュリティトラッカーページを参照してください。
    https://security-tracker.debian.org/tracker/linux

    Debian セキュリティアドバイザリに関する詳細、これらの更新をシステムに適用する方法、およびよくある質問については、こちらを参照してください。https://www.debian.org/security/

    メーリングリスト: debian-security-announce@lists.debian.org

前述の説明ブロックは、Tenable が Debian セキュリティアドバイザリから直接抽出したものです。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

ID	名前	製品	ファミリー	公開日	更新日	深刻度
350744	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98161	Nessus	Misc.	2026/9/25	2026/10/5	medium
364688	AlmaLinux 9.2 [TuxCare] セキュリティ更新:bpftool/kernel/kernel-64k/kernel-64k-core/kernel-64k-debug/etc 複数の脆弱性(ALMALINUX9.2:CLSA-2026:1791741836)	Nessus	Alma Linux Local Security Checks	2026/10/12	2026/10/13	critical
366507	Debian dsa-6568:ata-modules-6.12.111+deb13-armmp-di - セキュリティ更新	Nessus	Debian Local Security Checks	2026/10/16	2026/10/16	medium

検出

プラグインの検索

medium

critical

medium