リモートホストにインストールされているカーネルのバージョンは、5.10.269-270.1108より前のものです。したがって、ALAS2KERNEL-5.10-2026-133 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

    Linuxカーネルのvirtio-net/TAPネットワークパスの問題により、ゲスト仮想マシン内で特権アクセスを持つ攻撃者が、パッチが適用されていないLinuxカーネルバージョンを4.46.18実行しているKVMベースのハイパーバイザーでホストカーネルメモリを破損する特別に細工されたネットワークパケットを送信する可能性があります。これにより、ホストメモリの漏洩またはサービス拒否が発生する可能性があります。



    Linux カーネルで、以下の脆弱性が解決されています。

    netfilter:nf_tables:デバイス削除用にフックトランザクションを追加します(CVE-2026-63858)

    Linux カーネルで、以下の脆弱性が解決されています。

    bpf、skmsg:ktls rx による競合sk_data_ready判定を修正します

    sk_psock_strp_data_ready() はすでに tls_sw_has_ctx_rx() をチェックし、TLS RX コンテキストが存在するときに psock->saved_data_ready に延期し、受信キューの TLS strparser の所有権との競合を回避しています(コミット e91de6afa81c、bpf:実行中の sk_skb プログラムタイプを ktls で修正します)。

    sk_psock_verdict_data_ready() には同等のガードがありません。RX が構成される前にソケットTLS sockmap (BPF_SK_SKB_VERDICT) に挿入されると、tls_sw_strparser_arm() は sk_psock_verdict_data_readyas rx_ctx->saved_data_ready を保存します。データ到着時:

    tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready-> saved_data_ready() = sk_psock_verdict_data_ready()-> tcp_read_skb() は、tcp_eat_skb() を呼び出さずに __skb_unlink() を介してsk_receive_queueを排出するため、copied_seqはアドバンスされません。

    次にtls_strp_msg_load()はtcp_inq() >= full_len(stale)を見つけ、現在空のキューでcallstcp_recv_skb()を見つけ、WARN_ON_ONCE(!first)をヒットし、psock-owned(潜在的に解放されている)skbを指し示すrx_ctx->strp.anchor.frag_listで返します。tls_decrypt_sg()は、その後thatfrag_listをウォークして、メモリ解放後使用(Use After Free)を実行します。

    sk_psock_strp_data_ready() と同じ修正を適用します:TLS RX コンテキストが存在する場合、psock->saved_data_ready(sock_def_readable)を呼び出して wakerecv() wait を処理し、すぐに戻ってきます。受信キューに触れないようにします。TLSはキューの唯一の所有権を保持し、tls_sw_recvmsg() により通常レコードを復号化します。(CVE-2026-64025)

    Linux カーネルで、以下の脆弱性が解決されています。

    USB:iowarrior:切断競合での use-after-free を修正します(CVE-2026-64341)

    Linux カーネルで、以下の脆弱性が解決されています。

    ipvs:ヘッドの再割り当て後に IP ヘッダーをリロードします(CVE-2026-68476)

    Linux カーネルで、以下の脆弱性が解決されています。

    ipv4:igmp:igmp_gq_start_timer() の UAF の可能性を修正します(CVE-2026-72323)

    Linux カーネルで、以下の脆弱性が解決されています。

    bridge: stp: ブリッジを削除する際に発生する可能性のある use-after-free を修正 (CVE-2026-72389)

    Linux カーネルで、以下の脆弱性が解決されています。

    ipvlan:phy_dev から needed_headroom および needed_tailroom を継承します(CVE-2026-74744)

    Linux カーネルで、以下の脆弱性が解決されています。

    HID:magicmouse:入力がクレームされていない場合、古い msc->input を保持しません(CVE-2026-80782)

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4:新しい暗号化ファイルで DAX を有効にしません(CVE-2026-80806)

    Linux カーネルで、以下の脆弱性が解決されています。

    nilfs2:GC ioctl で無効なブロックインデックスを拒否します(CVE-2026-80807)

    Linux カーネルで、以下の脆弱性が解決されています。

    usb:usbfs:usbdev_release() の usb_device の use-after-free を修正します(CVE-2026-80824)

    Linux カーネルで、以下の脆弱性が解決されています。

    USB:シリアル:オプション:割り込み URB コールバックでのスラブ OOB 読み取りを修正します(CVE-2026-80827)

    Linux カーネルで、以下の脆弱性が解決されています。

    usb:core:usb_wakeup_notification() にロックを追加します(CVE-2026-80830)

    Linux カーネルで、以下の脆弱性が解決されています。

    ipv6:seg6:IPIP の非カプセル化で IPv4 コントロールブロックをクリアします(CVE-2026-80840)

    Linux カーネルで、以下の脆弱性が解決されています。

    xfrm:xfrm_state_construct() auth-trunc の漏洩を修正します(CVE-2026-80843)

    Linux カーネルで、以下の脆弱性が解決されています。

    RDMA/rxe:free_rd_atomic_resources() の OOB を修正します(CVE-2026-80863)

    Linux カーネルで、以下の脆弱性が解決されています: ipv4: validate checksum_start before completing checksum If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work. (CVE-2026-99999)

Tenable は、前述の記述ブロックをテスト済み製品のセキュリティアドバイザリから直接抽出しています。

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

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

    - ------------------------------------------------------------------------- Debian LTSアドバイザリ DLA-4777-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Salvatore Bonaccorso 2026年9月8日 https://wiki.debian.org/LTS
    - -------------------------------------------------------------------------

    パッケージ:linux バージョン: 6.1.187-1 CVE ID: CVE-2023-53706 CVE-2023-54141 CVE-2023-54263 CVE-2024-38620 CVE-2024-46754 CVE-2024-58094 CVE-2024-58095 CVE-2025-22104 CVE-2025-38117 CVE-2025-38203 CVE-2025-38206 CVE-2025-38237 CVE-2025-38616 CVE-2025-39833 CVE-2025-39901 CVE-2025-39925 CVE-2025-40054 CVE-2025-40064 CVE-2025-40102 CVE-2025-40139 CVE-2025-40168 CVE-2025-40206 CVE-2025-40307 CVE-2025-68794 CVE-2026-23394 CVE-2026-31419 CVE-2026-43491 CVE-2026-45963 CVE-2026-46111 CVE-2026-46158 CVE-2026-46170 CVE-2026-46266 CVE-2026-53089 CVE-2026-53090 CVE-2026-53361 CVE-2026-64082 CVE-2026-64139 CVE-2026-64192 CVE-2026-64270 CVE-2026-64272 CVE-2026-64280 CVE-2026-64294 CVE-2026-64434 CVE-2026-64507 CVE-2026-64508 CVE-2026-64542 CVE-2026-64543 CVE-2026-64561 CVE-2026-64562 CVE-2026-64563 CVE-2026-64564 CVE-2026-64565 CVE-2026-64567 CVE-2026-64569 CVE-2026-64571 CVE-2026-64572 CVE-2026-64573 CVE-2026-64576 CVE-2026-64577 CVE-2026-64578 CVE-2026-64579 CVE-2026-64580 CVE-2026-64581 CVE-2026-64582 CVE-2026-64583 CVE-2026-64584 CVE-2026-64586 CVE-2026-64590 CVE-2026-68082 CVE-2026-68093 CVE-2026-68096 CVE-2026-68099 CVE-2026-68100 CVE-2026-68104 CVE-2026-68106 CVE-2026-68108 CVE-2026-68111 CVE-2026-68115 CVE-2026-68117 CVE-2026-68121 CVE-2026-68123 CVE-2026-68124 CVE-2026-68125 CVE-2026-68127 CVE-2026-68129 CVE-2026-68130 CVE-2026-68131 CVE-2026-68132 CVE-2026-68135 CVE-2026-68136 CVE-2026-68137 CVE-2026-68138 CVE-2026-68140 CVE-2026-68141 CVE-2026-68142 CVE-2026-68143 CVE-2026-68144 CVE-2026-68146 CVE-2026-68147 CVE-2026-68148 CVE-2026-68151 CVE-2026-68153 CVE-2026-68154 CVE-2026-68155 CVE-2026-68156 CVE-2026-68157 CVE-2026-68158 CVE-2026-68159 CVE-2026-68160 CVE-2026-68162 CVE-2026-68164 CVE-2026-68165 CVE-2026-68169 CVE-2026-68175 CVE-2026-68176 CVE-2026-68180 CVE-2026-68181 CVE-2026-68182 CVE-2026-68183 CVE-2026-68184 CVE-2026-68186 CVE-2026-68187 CVE-2026-68188 CVE-2026-68189 CVE-2026-68190 CVE-2026-68192 CVE-2026-68194 CVE-2026-68195 CVE-2026-68196 CVE-2026-68197 CVE-2026-68198 CVE-2026-68199 CVE-2026-68202 CVE-2026-68204 CVE-2026-68206 CVE-2026-68207 CVE-2026-68209 CVE-2026-68210 CVE-2026-68212 CVE-2026-68213 CVE-2026-68214 CVE-2026-68215 CVE-2026-68216 CVE-2026-68217 CVE-2026-68218 CVE-2026-68222 CVE-2026-68223 CVE-2026-68226 CVE-2026-68227 CVE-2026-68229 CVE-2026-68231 CVE-2026-68234 CVE-2026-68243 CVE-2026-68244 CVE-2026-68246 CVE-2026-68248 CVE-2026-68249 CVE-2026-68250 CVE-2026-68251 CVE-2026-68253 CVE-2026-68254 CVE-2026-68255 CVE-2026-68259 CVE-2026-68269 CVE-2026-68277 CVE-2026-68278 CVE-2026-68279 CVE-2026-68280 CVE-2026-68284 CVE-2026-68294 CVE-2026-68297 CVE-2026-68299 CVE-2026-68300 CVE-2026-68301 CVE-2026-68302 CVE-2026-68304 CVE-2026-68309 CVE-2026-68310 CVE-2026-68313 CVE-2026-68315 CVE-2026-68320 CVE-2026-68322 CVE-2026-68324 CVE-2026-68325 CVE-2026-68326 CVE-2026-68327 CVE-2026-68328 CVE-2026-68331 CVE-2026-68333 CVE-2026-68335 CVE-2026-68336 CVE-2026-68338 CVE-2026-68340 CVE-2026-68343 CVE-2026-68344 CVE-2026-68349 CVE-2026-68350 CVE-2026-68351 CVE-2026-68352 CVE-2026-68353 CVE-2026-68354 CVE-2026-68355 CVE-2026-68357 CVE-2026-68359 CVE-2026-68360 CVE-2026-68361 CVE-2026-68362 CVE-2026-68363 CVE-2026-68365 CVE-2026-68366 CVE-2026-68367 CVE-2026-68368 CVE-2026-68369 CVE-2026-68370 CVE-2026-68371 CVE-2026-68373 CVE-2026-68376 CVE-2026-68377 CVE-2026-68386 CVE-2026-68388 CVE-2026-68395 CVE-2026-68397 CVE-2026-68398 CVE-2026-68402 CVE-2026-68403 CVE-2026-68405 CVE-2026-68406 CVE-2026-68407 CVE-2026-68410 CVE-2026-68411 CVE-2026-68413 CVE-2026-68414 CVE-2026-68417 CVE-2026-68422 CVE-2026-68425 CVE-2026-68427 CVE-2026-68428 CVE-2026-68430 CVE-2026-68431 CVE-2026-68432 CVE-2026-68433 CVE-2026-68434 CVE-2026-68444 CVE-2026-68446 CVE-2026-68450 CVE-2026-68451 CVE-2026-68452 CVE-2026-68476 CVE-2026-68480 CVE-2026-72012 CVE-2026-72015 CVE-2026-72017 CVE-2026-72023 CVE-2026-72030 CVE-2026-72035 CVE-2026-72040 CVE-2026-72041 CVE-2026-72045 CVE-2026-72051 CVE-2026-72057 CVE-2026-72062 CVE-2026-72063 CVE-2026-72065 CVE-2026-72069 CVE-2026-72070 CVE-2026-72077 CVE-2026-72096 CVE-2026-72099 CVE-2026-72110 CVE-2026-72113 CVE-2026-72114 CVE-2026-72115 CVE-2026-72116 CVE-2026-72117 CVE-2026-72118 CVE-2026-72119 CVE-2026-72121 CVE-2026-72124 CVE-2026-72125 CVE-2026-72142 CVE-2026-72146 CVE-2026-72157 CVE-2026-72170 CVE-2026-72172 CVE-2026-72191 CVE-2026-72216 CVE-2026-72236 CVE-2026-72237 CVE-2026-72242 CVE-2026-72252 CVE-2026-72253 CVE-2026-72260 CVE-2026-72262 CVE-2026-72299 CVE-2026-72305 CVE-2026-72308 CVE-2026-72323 CVE-2026-72392 CVE-2026-74436 CVE-2026-74441 CVE-2026-74443 CVE-2026-74444 CVE-2026-74446 CVE-2026-74450 CVE-2026-74453 CVE-2026-74454 CVE-2026-74455 CVE-2026-74456 CVE-2026-74457 CVE-2026-74458 CVE-2026-74459 CVE-2026-74460 CVE-2026-74461 CVE-2026-74463 CVE-2026-74464 CVE-2026-74465 CVE-2026-74467 CVE-2026-74468 CVE-2026-74469 CVE-2026-74470 CVE-2026-74471 CVE-2026-74472 CVE-2026-74473 CVE-2026-74475 CVE-2026-74476 CVE-2026-74478 CVE-2026-74479 CVE-2026-74480 CVE-2026-74481 CVE-2026-74482 CVE-2026-74485 CVE-2026-74487 CVE-2026-74488 CVE-2026-74490 CVE-2026-74492 CVE-2026-74493 CVE-2026-74494 CVE-2026-74495 CVE-2026-74497 CVE-2026-74498 CVE-2026-74499 CVE-2026-74505 CVE-2026-74507 CVE-2026-74508 CVE-2026-74509 CVE-2026-74510 CVE-2026-74512 CVE-2026-74514 CVE-2026-74515 CVE-2026-74516 CVE-2026-74518 CVE-2026-74519 CVE-2026-74522 CVE-2026-74523 CVE-2026-74525 CVE-2026-74540 CVE-2026-74546 CVE-2026-74547 CVE-2026-74548 CVE-2026-74549 CVE-2026-74550 CVE-2026-74551 CVE-2026-74552 CVE-2026-74553 CVE-2026-74555 CVE-2026-74556 CVE-2026-74557 CVE-2026-74563 CVE-2026-74564 CVE-2026-74566 CVE-2026-74567 CVE-2026-74569 CVE-2026-74575 CVE-2026-74577 CVE-2026-74579 CVE-2026-74580 CVE-2026-74581 CVE-2026-74582 CVE-2026-74583 CVE-2026-74585 CVE-2026-74586 CVE-2026-74587 CVE-2026-74588 CVE-2026-74589 CVE-2026-74594 CVE-2026-74595 CVE-2026-74597 CVE-2026-74598 CVE-2026-74601 CVE-2026-74603 CVE-2026-74604 CVE-2026-74607 CVE-2026-74608 CVE-2026-74609 CVE-2026-74612 CVE-2026-74613 CVE-2026-74614 CVE-2026-74615 CVE-2026-74616 CVE-2026-74620 CVE-2026-74621 CVE-2026-74622 CVE-2026-74623 CVE-2026-74624 CVE-2026-74625 CVE-2026-74626 CVE-2026-74628 CVE-2026-74630 CVE-2026-74631 CVE-2026-74632 CVE-2026-74635 CVE-2026-74636 CVE-2026-74637 CVE-2026-74641 CVE-2026-74647 CVE-2026-74648 CVE-2026-74649 CVE-2026-74650 CVE-2026-74651 CVE-2026-74654 CVE-2026-74656 CVE-2026-74657 CVE-2026-74658 CVE-2026-74659 CVE-2026-74660 CVE-2026-74662 CVE-2026-74663 CVE-2026-74664 CVE-2026-74666 CVE-2026-74667 CVE-2026-74668 CVE-2026-74669 CVE-2026-74671 CVE-2026-74672 CVE-2026-74673 CVE-2026-74675 CVE-2026-74676 CVE-2026-74678 CVE-2026-74679 CVE-2026-74680 CVE-2026-74682 CVE-2026-74683 CVE-2026-74688 CVE-2026-74689 CVE-2026-74691 CVE-2026-74692 CVE-2026-74693 CVE-2026-74694 CVE-2026-74696 CVE-2026-74697 CVE-2026-74701 CVE-2026-74704 CVE-2026-74705 CVE-2026-74714 CVE-2026-74717 CVE-2026-74719 CVE-2026-74720 CVE-2026-74722 CVE-2026-74724 CVE-2026-74726 CVE-2026-74730 CVE-2026-74737 CVE-2026-74739 CVE-2026-74743 CVE-2026-74744 CVE-2026-74746 CVE-2026-74748 CVE-2026-80527 CVE-2026-80528 CVE-2026-80529 CVE-2026-80534 CVE-2026-80536 CVE-2026-80539 CVE-2026-80540 CVE-2026-80541 CVE-2026-80547 CVE-2026-80548 CVE-2026-80549 CVE-2026-80550 CVE-2026-80552 CVE-2026-80553 CVE-2026-80555 CVE-2026-80557 CVE-2026-80558 CVE-2026-80559 CVE-2026-80560 CVE-2026-80561 CVE-2026-80562 CVE-2026-80565 CVE-2026-80567 CVE-2026-80568 CVE-2026-80569 CVE-2026-80570 CVE-2026-80572 CVE-2026-80573 CVE-2026-80574 CVE-2026-80583 CVE-2026-80584 CVE-2026-80586 CVE-2026-80589 CVE-2026-80590 CVE-2026-80678 CVE-2026-80679 CVE-2026-80680 CVE-2026-80681 CVE-2026-80684 CVE-2026-80686 CVE-2026-80706 CVE-2026-80707 CVE-2026-80708 CVE-2026-80709 CVE-2026-80714 CVE-2026-80715 CVE-2026-80716 CVE-2026-80717 CVE-2026-80718 CVE-2026-80722 CVE-2026-80725 CVE-2026-80726 CVE-2026-80730 CVE-2026-80731 CVE-2026-80732 CVE-2026-80733 CVE-2026-80737 CVE-2026-80742 CVE-2026-80743 CVE-2026-80744 CVE-2026-80752 CVE-2026-80754 CVE-2026-80756 CVE-2026-80757 CVE-2026-80762 CVE-2026-80763 CVE-2026-80764 CVE-2026-80765 CVE-2026-80766 CVE-2026-80767 CVE-2026-80768 CVE-2026-80770 CVE-2026-80772 CVE-2026-80781 CVE-2026-80782 CVE-2026-80783 CVE-2026-80784 CVE-2026-80788 CVE-2026-80789 CVE-2026-80790 CVE-2026-80791 CVE-2026-80792 CVE-2026-80793 CVE-2026-80794 CVE-2026-80795 CVE-2026-80796 CVE-2026-80797 CVE-2026-80798 CVE-2026-80799 CVE-2026-80800 CVE-2026-80801 CVE-2026-80802 CVE-2026-80803 CVE-2026-80805 CVE-2026-80806 CVE-2026-80807 CVE-2026-80808 CVE-2026-80809 CVE-2026-80812 CVE-2026-80814 CVE-2026-80819 CVE-2026-80823 CVE-2026-80824 CVE-2026-80826 CVE-2026-80827 CVE-2026-80828 CVE-2026-80829 CVE-2026-80830 CVE-2026-80831 CVE-2026-80832 CVE-2026-80840 CVE-2026-80842 CVE-2026-80843 CVE-2026-80844 CVE-2026-80846 CVE-2026-80848 CVE-2026-80852 CVE-2026-80854 CVE-2026-80855 CVE-2026-80856 CVE-2026-80863 CVE-2026-80888 CVE-2026-80890 CVE-2026-80891 CVE-2026-80892 CVE-2026-80893 CVE-2026-80901 CVE-2026-80902 CVE-2026-80904 CVE-2026-80906 CVE-2026-80908 CVE-2026-80909 CVE-2026-80910 CVE-2026-80913

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

    Debian 12 bookworm では、これらの問題はバージョン 6.1.187-1 で修正されています。

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

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

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

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

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

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

  - USB:シリアル:オプション:割り込み URB コールバックにおけるスラブ OOB 読み取りを修正。割り込み URB バッファは、エンドポイントの wMaxPacketSize に基づいて setup_port_interrupt_in() に割り当てられます: buffer_size = usb_endpoint_maxp(epd);
    ポート>interrupt_in_buffer = kmalloc(buffer_size、GFP_KERNEL);USB デバイスが割り込み IN エンドポイントで wMaxPacketSize = 8 を宣言すると、バッファは kmalloc-8 キャッシュから割り当てられます(正確には 8 バイト)。デバイスが短いパケット(wMaxPacketSize actual_length <)を送信すると、URBはステータス== 0で完了し、コールバックはdata[8]に評価されるdata[sizeof(struct usb_ctrlrequest)] の読み取りに進み、割り当てられた8バイトのバッファを超えて1バイトにアクセスします。これにより、スラブの領域外読み取りが発生します。欠如している境界チェックを追加することで、これを修正します:req_pkt->bRequestType と req_pkt->bRequest にアクセスする前に、実際の長さが構造体 usb_ctrlrequest ヘッダーを含めるのに十分な大きさであることをまず検証し、次に条件付きの中の data[sizeof(struct usb_ctrlrequest)] を読み取る前に、モデム信号の状態用の追加バイトがあることを検証します。一貫性を保つために、sizeof(struct usb_ctrlrequest) の代わりに sizeof(*req_pkt) を使用します。[johan:dev_err() を使用、シグナル宣言と初期化を分割](CVE-2026-80827)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs (CVE-2022-49100)

  - Linux カーネルでは、以下の脆弱性が解決されています: mtd: Fix device name leak when register device failed in add_mtd_device() There is a kmemleak when register device failed: unreferenced object 0xffff888101aab550 (size 8): comm insmod, pid 3922, jiffies 4295277753 (age 925.408s) hex dump (first 8 bytes): 6d 74 64 30 00 88 ff ff mtd0.... backtrace: [<00000000bde26724>]
    __kmalloc_node_track_caller+0x4e/0x150 [<000000003c32b416>] kvasprintf+0xb0/0x130 [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0 [<000000006e781163>] dev_set_name+0xab/0xe0 [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700 [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0 [<00000000c0d88488>] 0xffffffffa0238457 [<00000000b40d0922>] 0xffffffffa02a008f [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0 [<00000000770f6ca6>] do_init_module+0xdf/0x320 [<000000007b6768fe>] load_module+0x2f98/0x3330 [<00000000346bed5a>] __do_sys_finit_module+0x113/0x1b0 [<00000000674c2290>] do_syscall_64+0x35/0x80 [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If register device failed, should call put_device() to give up the reference. (CVE-2022-50566)

  - Linux カーネルでは、以下の脆弱性が解決されています: media: dvb-frontends: fix leak of memory fw (CVE-2022-50664)

  - Linux カーネルでは、以下の脆弱性が解決されています: acct: fix potential integer overflow in encode_comp_t() The integer overflow is descripted with following codes: > 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; > 343 return exp; > 344 } Currently comp_t is defined as type of '__u16', but the variable 'exp' is type of 'int', so overflow would happen when variable 'exp' in line 343 is greater than 65535. (CVE-2022-50749)

  - Linux カーネルでは、以下の脆弱性が解決されています: ext2: Add sanity checks for group and filesystem size Add sanity check that filesystem size does not exceed the underlying device size and that group size is big enough so that metadata can fit into it. This avoid trying to mount some crafted filesystems with extremely large group counts. (CVE-2022-50815)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg() syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory. Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at if (pkt_len > 2 * MAX_RX_BUF_SIZE) { line in ath9k_hif_usb_rx_stream(). We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter. Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol. (CVE-2022-50709)

  - Linux カーネルでは、以下の脆弱性が解決されています: configfs: fix possible memory leak in configfs_create_dir() kmemleak reported memory leaks in configfs_create_dir(): unreferenced object 0xffff888009f6af00 (size 192): comm modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace:
    kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... unreferenced object 0xffff888003ba7180 (size 96): comm modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... This is because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing as: configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ...
    *dentry_unlink_inode()* configfs_d_iput() # s_count = 0, release However, if we failed in configfs_create(): configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode); There is no inode in the error path, so the configfs_d_iput() is lost and makes sd and fragment memory leaked. To fix this, when we failed in configfs_create(), manually call configfs_put(sd) to keep the refcount correct. (CVE-2022-50751)

  - Linux カーネルでは、以下の脆弱性が解決されています: pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP An oops can be induced by running 'cat /proc/kcore > /dev/null' on devices using pstore with the ram backend because kmap_atomic() assumes lowmem pages are accessible with __va(). Unable to handle kernel paging request at virtual address ffffff807ff2b000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000 [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: dm_integrity CPU:
    7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x110/0x260 lr : vread+0x194/0x294 sp :
    ffffffc013ee39d0 x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000 x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000 x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21:
    ffffffc0085a2000 x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60 x14: ffffffffad588000 x13: 0000000000000000 x12:
    0000000000000001 x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 :
    ffffffc013ee3a78 x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000 Call trace:
    __memcpy+0x110/0x260 read_kcore+0x584/0x778 proc_reg_read+0xb4/0xe4 During early boot, memblock reserves the pages for the ramoops reserved memory node in DT that would otherwise be part of the direct lowmem mapping. Pstore's ram backend reuses those reserved pages to change the memory type (writeback or non-cached) by passing the pages to vmap() (see pfn_to_page() usage in persistent_ram_vmap() for more details) with specific flags. When read_kcore() starts iterating over the vmalloc region, it runs over the virtual address that vmap() returned for ramoops. In aligned_vread() the virtual address is passed to vmalloc_to_page() which returns the page struct for the reserved lowmem area. That lowmem page is passed to kmap_atomic(), which effectively calls page_to_virt() that assumes a lowmem page struct must be directly accessible with __va() and friends. These pages are mapped via vmap() though, and the lowmem mapping was never made, so accessing them via the lowmem virtual address oopses like above. Let's side-step this problem by passing VM_IOREMAP to vmap(). This will tell vread() to not include the ramoops region in the kcore. Instead the area will look like a bunch of zeros. The alternative is to teach kmap() about vmalloc areas that intersect with lowmem. Presumably such a change isn't a one-liner, and there isn't much interest in inspecting the ramoops region in kcore files anyway, so the most expedient route is taken for now. (CVE-2022-50849)

  - Linux カーネルでは、以下の脆弱性が解決されています: hwrng: amd - Fix PCI device refcount leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the normal and error path. (CVE-2022-50868)

  - Linux カーネルでは、以下の脆弱性が解決されています: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. (CVE-2023-52515)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
351155	Debian dsa-6528:ata-modules-6.12.111+deb13-armmp-di - セキュリティ更新	Nessus	Debian Local Security Checks	2026/9/29	2026/9/29	high
363954	Oracle Linux 8 / 9 : Unbreakable Enterprise カーネル (ELSA-2026-500377)	Nessus	Oracle Linux Local Security Checks	2026/10/7	2026/10/7	high
362907	Debian dla-4817:ata-modules-6.12.107+deb12-armmp-di - セキュリティ更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high
365191	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2026-133)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/19	high
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise カーネル (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
343851	Debian dla-4777:ata-modules-6.1.0-52-armmp-di - セキュリティ更新	Nessus	Debian Local Security Checks	2026/9/8	2026/9/8	high
342987	Linux Distros のパッチ未適用の脆弱性: CVE-2026-80827	Nessus	Misc.	2026/9/4	2026/11/6	high
369516	CentOS Linux 6 [TuxCare] セキュリティ更新プログラム:カーネル/kernel-abi-whitelists/kernel-debug/kernel-debug-devel/etcの複数の脆弱性(CENTOS6:CLSA-2026:1792245431)	Nessus	CentOS Local Security Checks	2026/10/21	2026/11/2	high
374124	CentOS Linux 7 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-debug/kernel-debug-devel/kernel-devel/etcの複数の脆弱性(CENTOS7:CLSA-2026:1792976962)	Nessus	CentOS Local Security Checks	2026/10/30	2026/10/30	high

検出

プラグインの検索

high

high

high

high

high

high

high

high

high