There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: apparmor: fix deadlock in complain-
    mode change_hat The use of change_hat when in complain mode can cause a deadlock when the hat doesn't
    exist and a new learning profile is created for the missing profile. This is because change_hat() has
    taken the lock to search the hat list and creating the new learning profile needs to take the lock to add
    it to the list. From the bug report: Originally found in 7.0.0 in LTS ubuntu 26.04 with pam_apparmor + su
    in complain mode set to change hats. Then verified in newest available vanilla kernel I've compiled to see
    if still present: 7.2-rc7 vanilla -> affected checked also some other kernels: 6.18.44 vanilla -> affected
    6.12.95 with debian patches -> unaffected On systems without bug (for example 6.12.95 debian) it just
    prints: aa_change_hat rc=0 On systems with bug, the executable always hangs, prints nothing and becomes
    unkillable. (And once stuck this way, it will cause any further hat changes to also cause the changing
    process to get stuck) Then in syslog you can find hint about cause: kernel: INFO: task hat:3409 blocked
    for more than 483 seconds. kernel: Not tainted 7.2.0-rc7 #1 kernel: "echo 0 >
    /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: task:hat state:D stack:0 pid:3409
    tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel: <TASK> kernel:
    __schedule+0x48f/0xfe0 kernel: schedule+0x27/0xa0 kernel: schedule_preempt_disabled+0x15/0x30 kernel:
    __mutex_lock.constprop.0+0x569/0xa10 kernel: aa_new_learning_profile+0x15f/0x210 kernel:
    build_change_hat+0x19f/0x3b0 kernel: change_hat.isra.0+0x5dd/0xd60 kernel: aa_change_hat+0x2f3/0x710
    kernel: aa_setprocattr_changehat+0x121/0x1f0 kernel: do_setattr+0x28c/0x340 kernel:
    apparmor_setselfattr+0x20/0x50 kernel: security_setselfattr+0xf6/0x110 kernel:
    __x64_sys_lsm_set_self_attr+0x53/0x90 kernel: do_syscall_64+0xdd/0x5e0 kernel: ?
    __mod_memcg_lruvec_state+0xfd/0x260 kernel: ? lruvec_stat_mod_folio+0x8d/0xd0 kernel: ?
    __folio_mod_stat+0x2d/0x90 kernel: ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel: ?
    do_anonymous_page+0x184/0xa10 kernel: ? __handle_mm_fault+0x805/0x870 kernel: ?
    count_memcg_events+0xef/0x230 kernel: ? handle_mm_fault+0x1f0/0x2f0 kernel: ?
    do_user_addr_fault+0x2bb/0x7b0 kernel: ? do_syscall_64+0x94/0x5e0 kernel: ? exc_page_fault+0x75/0x160
    kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP:
    002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX:
    0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI:
    0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10:
    0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14:
    0000000000000046 R15: 0000000000000064 kernel: </TASK> kernel: INFO: task hat:3409 is blocked on a mutex
    likely owned by task hat:3409. To fix the issue, lift the locking out of the core of
    aa_new_learning_profile(), introduce a wrapper function that takes the lock where needed, and have
    build_change_hat() call the core function that no longer takes the lock. In addition fix 4 other issues
    introduced by commit 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child
    profiles") - aa_get_profile_rcu() was replaced-by: aa_get_profile without the accompanying
    rcu_dereference_protected() - an extra aa_get_label(label) was introduced at the start of change_hat()
    without an accompanying aa_put_label() causing a reference count leak. - a reference count leak was
    introduced in the label_is_stale(label) case, where the newest profile would be leaked instead of the
    label passed to the function. - a potential UAF when the lookup walks up the tree with new_ns != ns the
    new label refere ---truncated--- (CVE-2026-90179)

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

  - AppArmor：修正抱怨模式中的鎖死 change_hat 當帽子不存在且為遺漏的設定檔建立新的學習設定檔時，在抱怨模式下使用 change_hat 可能會導致鎖死。這是因為 change_hat（） 已取得鎖定以搜尋帽子清單，而建立新的學習設定檔需要取得鎖定才能將其新增至清單。來自錯誤報告：最初在 LTS ubuntu 26.04 中7.0.0發現，在投訴模式下將 pam_apparmor + su 設置為更換帽子。然後在我編譯的最新可用原版內核中進行驗證，看看是否仍然存在：7.2-rc7 vanilla -> 受影響還檢查了其他一些內核：
    6.18.44 vanilla -> 受到 debian 修補程式的影響 6.12.95 -> 不受影響 在沒有錯誤的系統（例如 6.12.95 debian）上，它只會列印： aa_change_hat rc=0 在有錯誤的系統上，可執行檔總是懸置，不列印任何內容並且變得無法殺死。（一旦卡住這樣，就會導致任何進一步的帽子更改，也會導致更改過程卡住）然後在 syslog 中，您可以找到有關原因的提示： 核心： INFO：
    task hat：3409 被封鎖超過 483 秒。核心：未受污染 7.2.0-rc7 #1 核心：echo 0 > /proc/sys/kernel/hung_task_timeout_secs 停用此訊息。 核心：task：hat state：D stack：0 pid：3409 tgid：3409 ppid：2605 task_flags：0x400000 flags：0x00080800 核心： 呼叫追蹤： 核心： <TASK> 核心：
    __schedule+0x48f/0xfe0 核心：schedule+0x27/0xa0 核心：schedule_preempt_disabled+0x15/0x30 核心：
    __mutex_lock.constprop.0+0x569/0xa10 核心： aa_new_learning_profile+0x15f/0x210 核心：
    build_change_hat+0x19f/0x3b0 核心：change_hat.isra.0+0x5dd/0xd60 核心：aa_change_hat+0x2f3/0x710 核心：aa_setprocattr_changehat+0x121/0x1f0 核心：do_setattr+0x28c/0x340 核心：
    apparmor_setselfattr+0x20/0x50 核心： security_setselfattr+0xf6/0x110 核心：
    __x64_sys_lsm_set_self_attr+0x53/0x90 核心：do_syscall_64+0xdd/0x5e0 核心：？
    __mod_memcg_lruvec_state+0xfd/0x260核心：？lruvec_stat_mod_folio+0x8d/0xd0核心：？
    __folio_mod_stat+0x2d/0x90核心：？map_anon_folio_pte_nopf+0xd1/0x1f0 核心：？do_anonymous_page+0x184/0xa10核心：？__handle_mm_fault+0x805/0x870核心：？count_memcg_events+0xef/0x230 核心：？handle_mm_fault+0x1f0/0x2f0 核心：？do_user_addr_fault+0x2bb/0x7b0核心：？do_syscall_64+0x94/0x5e0核心：？exc_page_fault+0x75/0x160 核心：entry_SYSCALL_64_after_hwframe+0x76/0x7e 核心：RIP：0033：0x7f815e134c8d 核心：RSP：
    002b：00007fff6df94ea8 EFLAGS：00000246 ORIG_RAX：0000000000001cc 核心：RAX：ffffffffffffffda RBX：
    0000556d8c81d040 RCX：00007f815e134c8d 核心：RDX：0000000000000046 RSI：0000556d8c81d040 RDI：
    0000000000000064 核心： RBP： 00007fff6df94ef0 R08： 00007f815e212ac8 R09： 000000000000000c 核心： R10：
    0000000000000000 R11： 0000000000000246 R12： 0000556d8c81d010 核心： R13： 0000000000000026 R14：
    0000000000000046 R15：0000000000000064 核心：核心： </TASK> 資訊：任務 hat：3409 在任務 hat：3409 可能擁有的互斥體上被封鎖。若要解決此問題，請解除 aa_new_learning_profile（） 核心的鎖定，引入一個包裝函式在需要時進行鎖定，並讓 build_change_hat（） 呼叫不再採用鎖定的核心函式。此外，還修正了提交 32e92764d6f8d 引入的 4 個其他問題 （apparmor：在查詢 changehat 子設定檔時抓取 ns 鎖定和重新整理） - aa_get_profile_rcu（） 被替換為： aa_get_profile 沒有隨附的 rcu_dereference_protected（） - 在 change_hat（） 的開頭引入了一個額外的 aa_get_label（標籤），沒有隨附的 aa_put_label（），導致參照計數洩漏。- 在 label_is_stale（label） 案例中引入了參照計數洩漏，其中最新的設定檔會洩漏，而不是傳遞給函式的標籤。- 當查找以 new_ns ！= ns 新標籤參照 ---truncated--- （CVE-2026-90179） 時，當查找向上走動時，潛在的 UAF

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

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

  - apparmor：修复 complain 模式中的死锁 change_hat 在 change_hat 不存在 Hat 且为缺少的配置文件创建新的学习配置文件时，在抱怨模式下使用  可导致死锁。这是因为 change_hat（） 已获取锁定以搜索帽子列表，并且创建新的学习档案需要获取锁定以将其添加到列表中。来自缺陷报告：最初在 LTS ubuntu 26.04 中7.0.0发现，在抱怨模式下 pam_apparmor + su 设置为更改帽子。然后在我编译的最新可用 vanilla 内核中进行验证，看看是否仍然存在：7.2-rc7 vanilla -> 受影响还检查了其他一些内核：
    6.18.44 vanilla -> 受 Debian 修补程序影响 6.12.95 -> 不受影响 在没有错误的系统（例如 6.12.95 debian）上，它仅打印：aa_change_hat rc=0 在有错误的系统上，可执行文件始终挂起，不打印任何内容并且变得不可终止。（一旦以这种方式卡住，它将导致任何进一步的帽子更改，也会导致更改进程卡住）然后在 syslog 中，您可以找到有关原因的提示：kernel：INFO：
    task hat：3409 被阻断超过 483 秒。kernel： 未受感染 7.2.0-rc7 #1 kernel： echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 kernel： task：hat state：D stack：0 pid：3409 tgid：3409 ppid：2605 task_flags：0x400000 flags：0x00080800 kernel： 调用跟踪： kernel： <TASK> kernel：
    __schedule+0x48f/0xfe0 内核：schedule+0x27/0xa0 内核：schedule_preempt_disabled+0x15/0x30 内核：
    __mutex_lock.constprop.0+0x569/0xa10 内核：aa_new_learning_profile+0x15f/0x210 内核：
    build_change_hat+0x19f/0x3b0 内核：change_hat.isra.0+0x5dd/0xd60 内核：aa_change_hat+0x2f3/0x710 内核：aa_setprocattr_changehat+0x121/0x1f0 内核：do_setattr+0x28c/0x340 内核：
    apparmor_setselfattr+0x20/0x50 内核： security_setselfattr+0xf6/0x110 内核：
    __x64_sys_lsm_set_self_attr+0x53/0x90 内核：do_syscall_64+0xdd/0x5e0 内核：？
    __mod_memcg_lruvec_state+0xfd/0x260 内核：？lruvec_stat_mod_folio+0x8d/0xd0 内核：？
    __folio_mod_stat+0x2d/0x90 内核：？map_anon_folio_pte_nopf+0xd1/0x1f0 内核：？do_anonymous_page+0x184/0xa10 内核：？__handle_mm_fault+0x805/0x870 内核：？count_memcg_events+0xef/0x230 内核：？handle_mm_fault+0x1f0/0x2f0 内核：？do_user_addr_fault+0x2bb/0x7b0 内核：？do_syscall_64+0x94/0x5e0 内核：？exc_page_fault+0x75/0x160 内核：entry_SYSCALL_64_after_hwframe+0x76/0x7e 内核：RIP：0033：0x7f815e134c8d 内核：RSP：
    002b：00007fff6df94ea8 EFLAGS：00000246 ORIG_RAX：00000000000001cc 内核： RAX：ffffffffffffffda RBX：
    0000556d8c81d040 RCX： 00007f815e134c8d 内核： RDX： 0000000000000046 RSI： 0000556d8c81d040 RDI：
    0000000000000064 kernel： RBP： 00007fff6df94ef0 R08： 00007f815e212ac8 R09： 000000000000000c kernel： R10：
    00000000000000000 R11：0000000000000246 R12：0000556d8c81d010 kernel： R13：0000000000000026 R14：
    0000000000000046 R15： 0000000000000064 kernel： </TASK> kernel： INFO： task hat：3409 在可能由任务 hat：3409 拥有的互斥体上被阻断。要解决此问题，解除 aa_new_learning_profile（） 核心的锁定，引入一个包装函数在需要时获取锁定，并使 build_change_hat（） 调用不再获取锁定的核心函数。此外，还修复了提交 32e92764d6f8d 引入的 4 个其他问题（apparmor：查找 changehat 子配置文件时，抓取 ns 锁定并刷新） - aa_get_profile_rcu（） 替换为：aa_get_profile，缺少随附的 rcu_dereference_protected（） - 在缺少随附 aa_put_label（） 的 change_hat（） 开头引入了一个额外的 aa_get_label（label），从而导致引用计数泄漏。- 在 label_is_stale（label） 情况下引入了引用计数泄漏，其中会泄漏最新的配置文件，而不是传递给函数的标签。- 查找在树上行走时可能存在 UAF，new_ns ！= ns，新标签引用 ---truncated--- （CVE-2026-90179）

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

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

  - apparmor:苦情モードのデッドロックを修正します change_hat 苦情モードのときに change_hat を使用すると、hat が存在せず、欠落しているプロファイルに対して新しい学習プロファイルが作成されるときにデッドロックが発生する可能性があります。これは、change_hat()がハットリストを検索するためにロックをかけており、新しい学習プロファイルを作成するには、ハットリストに追加するためにロックをかける必要があるためです。バグレポートから:元々は、ハットを変更するために設定された苦情モードでpam_apparmor + suを使用したLTS ubuntu 26.04の7.0.0で発見されました。次に、まだ存在するかどうかを確認するためにコンパイルした最新の利用可能なバニラカーネルで検証しました:7.2-rc7 vanilla ->影響を受ける他のカーネルもチェックしました:
    6.18.44 vanilla -> Debian パッチで影響を受ける 6.12.95 -> 影響なし バグのないシステム(たとえば debian)では、次のように出力されますaa_change_hat 6.12.95 rc=0 バグのあるシステムでは、実行可能ファイルは常にハングし、何も出力せず、kill できない状態になります。(この方法でスタックすると、それ以上のハットの変更が発生し、変更プロセスもスタックします)次にsyslogで、原因に関するヒントを見つけることができます:カーネル:情報:
    タスク hat:3409 が 483 秒以上ブロックされる。カーネル: 汚染されていません 7.2.0-rc7 #1 カーネル: echo 0 > /proc/sys/kernel/hung_task_timeout_secs このメッセージを無効にします。 カーネル:task:hat state:D stack:0 pid:3409 tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 カーネル:コールトレース:カーネル: <TASK> カーネル:
    __schedule+0x48f/0xfe0 カーネル:schedule+0x27/0xa0 カーネル:schedule_preempt_disabled+0x15/0x30 カーネル:
    __mutex_lock.constprop.0+0x569/0xa10カーネル: aa_new_learning_profile+0x15f/0x210カーネル:
    build_change_hat+0x19f/0x3b0 カーネル: change_hat.isra.0+0x5dd/0xd60 カーネル: aa_change_hat+0x2f3/0x710 カーネル: aa_setprocattr_changehat+0x121/0x1f0 カーネル: do_setattr+0x28c/0x340 カーネル:
    apparmor_setselfattr+0x20/0x50 カーネル: security_setselfattr+0xf6/0x110 カーネル:
    __x64_sys_lsm_set_self_attr+0x53/0x90 カーネル: do_syscall_64+0xdd/0x5e0 カーネル: ?
    __mod_memcg_lruvec_state+0xfd/0x260 カーネル:?lruvec_stat_mod_folio+0x8d/0xd0 カーネル:?
    __folio_mod_stat+0x2d/0x90 カーネル:?map_anon_folio_pte_nopf+0xd1/0x1f0 カーネル:?do_anonymous_page+0x184/0xa10カーネル:?__handle_mm_fault+0x805/0x870 カーネル:?count_memcg_events+0xef/0x230 カーネル:?handle_mm_fault+0x1f0/0x2f0カーネル:?do_user_addr_fault+0x2bb/0x7b0カーネル:?do_syscall_64+0x94/0x5e0カーネル:?exc_page_fault+0x75/0x160 カーネル: entry_SYSCALL_64_after_hwframe+0x76/0x7e カーネル: RIP: 0033:0x7f815e134c8d カーネル: RSP:
    002b:00007fff6df94ea8 EFLAGS:00000246 ORIG_RAX:000000000000001ccカーネル:RAX:ffffffffffffffda RBX:
    0000556d8c81d040 RCX:00007f815e134c8d kernel:RDX:0000000000000046 RSI:0000556d8c81d040 RDI:
    0000000000000064 カーネル:RBP:00007fff6df94ef0 R08:00007f815e212ac8 R09:000000000000000c カーネル: R10:
    00000000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 カーネル: R13: 0000000000000026 R14:
    0000000000000046 R15:0000000000000064 カーネル: </TASK> カーネル: 情報: タスク hat:3409 は、タスク hat:3409 が所有していると思われる mutex でブロックされています。この問題を修正するには、aa_new_learning_profile() のコアからロックアウトを解除し、必要な場所でロックを取得するラッパー関数を導入し、ロックを取りbuild_change_hatとならないコア関数を () に呼び出しさせます。さらに、コミット 32e92764d6f8d により導入された 4 つの他の問題を修正します(apparmor:changehat 子プロファイルを検索する際、ns ロックをグラブしてリフレッシュ) - aa_get_profile_rcu() が置換されました:付随する rcu_dereference_protected() のない aa_get_profile - 付随する aa_put_label() なしで、change_hat() の先頭に追加の aa_get_label(label) が導入され、参照カウントの漏洩を引き起こしました。- label_is_stale(label)のケースで、参照カウントの漏洩が導入され、関数に渡されるラベルの代わりに、最新のプロファイルが漏洩します。- 検索が new_ns != ns でツリーを登るときの UAF の可能性 新しいラベル refere ---truncated--- (CVE-2026-90179)

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

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

  - apparmor: fix deadlock in complain-mode change_hat The use of change_hat when in complain mode can cause a     deadlock when the hat doesn't exist and a new learning profile is created for the missing profile. This is     because change_hat() has taken the lock to search the hat list and creating the new learning profile needs     to take the lock to add it to the list. From the bug report: Originally found in 7.0.0 in LTS ubuntu 26.04     with pam_apparmor + su in complain mode set to change hats. Then verified in newest available vanilla     kernel I've compiled to see if still present: 7.2-rc7 vanilla -> affected checked also some other kernels:
    6.18.44 vanilla -> affected 6.12.95 with debian patches -> unaffected On systems without bug (for example     6.12.95 debian) it just prints: aa_change_hat rc=0 On systems with bug, the executable always hangs,     prints nothing and becomes unkillable. (And once stuck this way, it will cause any further hat changes to     also cause the changing process to get stuck) Then in syslog you can find hint about cause: kernel: INFO:
    task hat:3409 blocked for more than 483 seconds. kernel: Not tainted 7.2.0-rc7 #1 kernel: echo 0 >     /proc/sys/kernel/hung_task_timeout_secs disables this message. kernel: task:hat state:D stack:0 pid:3409     tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel: <TASK> kernel:
    __schedule+0x48f/0xfe0 kernel: schedule+0x27/0xa0 kernel: schedule_preempt_disabled+0x15/0x30 kernel:
    __mutex_lock.constprop.0+0x569/0xa10 kernel: aa_new_learning_profile+0x15f/0x210 kernel:
    build_change_hat+0x19f/0x3b0 kernel: change_hat.isra.0+0x5dd/0xd60 kernel: aa_change_hat+0x2f3/0x710     kernel: aa_setprocattr_changehat+0x121/0x1f0 kernel: do_setattr+0x28c/0x340 kernel:
    apparmor_setselfattr+0x20/0x50 kernel: security_setselfattr+0xf6/0x110 kernel:
    __x64_sys_lsm_set_self_attr+0x53/0x90 kernel: do_syscall_64+0xdd/0x5e0 kernel: ?
    __mod_memcg_lruvec_state+0xfd/0x260 kernel: ? lruvec_stat_mod_folio+0x8d/0xd0 kernel: ?
    __folio_mod_stat+0x2d/0x90 kernel: ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel: ?     do_anonymous_page+0x184/0xa10 kernel: ? __handle_mm_fault+0x805/0x870 kernel: ?     count_memcg_events+0xef/0x230 kernel: ? handle_mm_fault+0x1f0/0x2f0 kernel: ?     do_user_addr_fault+0x2bb/0x7b0 kernel: ? do_syscall_64+0x94/0x5e0 kernel: ? exc_page_fault+0x75/0x160     kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP:
    002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX:
    0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI:
    0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10:
    0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14:
    0000000000000046 R15: 0000000000000064 kernel: </TASK> kernel: INFO: task hat:3409 is blocked on a mutex     likely owned by task hat:3409. To fix the issue, lift the locking out of the core of     aa_new_learning_profile(), introduce a wrapper function that takes the lock where needed, and have     build_change_hat() call the core function that no longer takes the lock. In addition fix 4 other issues     introduced by commit 32e92764d6f8d (apparmor: grab ns lock and refresh when looking up changehat child     profiles) - aa_get_profile_rcu() was replaced-by: aa_get_profile without the accompanying     rcu_dereference_protected() - an extra aa_get_label(label) was introduced at the start of change_hat()     without an accompanying aa_put_label() causing a reference count leak. - a reference count leak was     introduced in the label_is_stale(label) case, where the newest profile would be leaked instead of the     label passed to the function. - a potential UAF when the lookup walks up the tree with new_ns != ns the     new label refere ---truncated--- (CVE-2026-90179)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
475803	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 20198.0.0	Tenable Self-Hosted Container Security	Google COS Security Checks	2026/10/16	2026/10/16	high
475803	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 20198.0.0	Tenable Cloud Security	Google COS Security Checks	2026/10/16	2026/10/16	high
347578	Linux Distros 未修補弱點：CVE-2026-90179	Nessus	Misc.	2026/9/18	2026/11/4	high
347578	Linux Distros 未修补的漏洞：CVE-2026-90179	Nessus	Misc.	2026/9/18	2026/11/4	high
347578	Linux Distros のパッチ未適用の脆弱性: CVE-2026-90179	Nessus	Misc.	2026/9/18	2026/11/4	high
347578	Linux Distros Unpatched Vulnerability : CVE-2026-90179	Nessus	Misc.	2026/9/18	2026/11/4	high
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	2026/11/5	2026/11/5	high

検出

プラグインの検索

high

high

high

high

high

high

high