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

  - btrfs：始終等待有序範圍以避免 OE 爭用 [BUG] Syzbot 報告了一個錯誤，指出同一範圍可能存在衝突的 OE： BTRFS 嚴重 （device loop4）：insert_ordered_extent：264 中的錯誤：
    重疊有序範圍，現有 OE file_offset 16384 num_bytes 430080 旗標0x1089，新 OE file_offset 16384 num_bytes 430080 旗標0x80 （errno=-17 物件 alrea[ 179.162726][ T6897] BTRFS 嚴重 （device loop4）：insert_ordered_extent：264 中的錯誤：重疊有序範圍，現有 OE file_offset 16384 num_bytes 430080 旗標0x1089，新 OE file_offset 16384 num_bytes 430080 旗標0x80 （errno=-17 物件已存在） ------------[ 切到此處 ]------------ fs/btrfs/ordered-data 的核心錯誤。c：264！硬體名稱：Google Google Compute Engine/Google Compute Engine、BIOS Google 05/09/2026 RIP：
    0010：btrfs_alloc_ordered_extent+0x943/0xad0呼叫追蹤： <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 0000000000000000000 ]--- [CAUSE] 自從提交 ff66fe666233 （btrfs：修正附加直接寫入的錯誤緩衝 IO 後援） 以來，如果直接 IO 短時間結束，我們會將 isize 還原回原來的 isize，以便在緩衝後援期間可以遵守附加寫入。通常，我們在緩衝回寫期間依賴 lock_and_cleanup_extent_if_need（） 函式來等候任何現有的有序範圍。但只有在start_pos位於 isize 內時，才會發生有序範圍等待。由於我們已在失敗的直接 IO 期間還原 isize，因此我們不會等候任何有序範圍。這表示我們可以進行直接 IO OE 仍在樹狀結構中、完成但尚未移除的爭用，然後我們插入緩衝寫入的 OE，導致上述損毀。[修復]讓 OE 等待無條件，以處理還原的 isize 情況。由於 lock_and_cleanup_extent_if_need（） 現在要麼鎖定範圍，要麼傳回 -EAGAIN，因此也要移除處理無範圍鎖定案例的分支，並重新命名它以移除 _if_need 字尾。以下微基準測試顯示了 btrfs_buffered_write（） 的運行時間差異，執行“xfs_io -f -c pwrite 0 1m”工作負載，所有值都是以納秒為單位的平均運行時間。函式執行階段 |之前 |之後
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need（） | 58.2183.0 |btrfs_buffered_write（） | 2115.62973.3 |btrfs_buffered_write（） 的整體運行時間仍然很小（仍然不到 3 微秒），我想說額外的成本仍然是可以接受的。解決此問題的替代方法是在 iomap_end（） 期間等待有序範圍，其中 isize 還原已完成。但該解決方案將破壞 nowait 要求，就像 nowait 直接 IO 短時間結束一樣，我們必須無條件地等待 OE，否則下一個附加緩衝 IO 仍然會遇到相同的問題。所以這裡我們必須將等待成本移至緩衝寫入，但至少程式碼稍微精簡一些。（CVE-2026-90264）

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

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

  - btrfs：始终等待有序盘区以避免 OE 争用 [缺陷] Syzbot 报告一个缺陷，同一范围内可能存在冲突的 OE： BTRFS 危急 （device loop4）：insert_ordered_extent：264 中的错误：
    重叠有序盘区，现有 OE file_offset 16384 num_bytes 430080 标记0x1089，新 OE file_offset 16384 num_bytes 430080 标记0x80 （errno=-17 对象 alrea[ 179.162726][ T6897] BTRFS 危急 （device loop4）：insert_ordered_extent：264 中的错误：重叠有序盘区，现有 OE file_offset 16384 num_bytes 430080 标记0x1089，新 OE file_offset 16384 num_bytes 430080 标记0x80（errno=-17 对象已存在）------------[ cut here ]------------ fs/btrfs/ordered-data 处的内核缺陷。C：264！硬件名称：Google Google Compute Engine/Google Compute Engine、BIOS Google 05/09/2026 RIP：
    0010：btrfs_alloc_ordered_extent+0x943/0xad0 调用跟踪： <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 000000000000000000 ]--- [CAUSE] Since commit ff66fe666233（btrfs：修复针对附加直接写入的错误缓冲 IO 回退），如果直接 IO 完成较短，我们会将 isize 恢复回原始 isize，以便在缓冲的回退期间可遵守附加写入。通常，在缓冲的回写期间，我们依靠 lock_and_cleanup_extent_if_need（） 函数等待任何现有的有序盘区。但只有当start_pos位于 isize 内时，才会发生有序盘区等待。由于我们已在失败的直接 IO 期间恢复 isize，因此不会等待任何有序盘区。这意味着我们可发生争用，其中直接 IO OE 仍在树中、已完成但尚未删除，然后我们要为缓冲写入插入 OE，从而导致上述崩溃。[修复]使 OE 无条件等待，以处理恢复的 isize 情况。由于 lock_and_cleanup_extent_if_need（） 现在可以锁定盘区或返回 -EAGAIN，因此还要删除处理非盘区锁定情况的分支，并对其重命名以删除_if_need后缀。以下微基准测试显示了 btrfs_buffered_write（） 的运行时间差异，执行“xfs_io -f -c pwrite 0 1m”工作负载，所有值都是以纳秒为单位的平均运行时间。函数运行时 |之前 |之后
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need（） | 58.2183.0 |btrfs_buffered_write（） | 2115.62973.3 |btrfs_buffered_write（） 的整体运行时间仍然很小（仍然不到 3 微秒），我想说额外的成本仍然是可以接受的。修复此问题的替代方法是在 iomap_end（） 期间等待有序盘区，此时完成 isize 恢复。但该解决方案将破坏 nowait 要求，就像 nowait 直接 IO 结束较短一样，我们必须无条件等待 OE，否则下一个附加缓冲的 IO 仍会遇到同样的问题。所以这里我们必须将等待成本转移到缓冲写入，但至少代码稍微精简一些。（CVE-2026-90264）

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

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

  - btrfs:OE 競合を回避するために、順序付けられたエクステントを常に待機します [バグ] Syzbot は、同じ範囲に対して競合する OE が存在する可能性があるバグを報告しました: BTRFS 重要度最高(デバイス loop4): insert_ordered_extent:264 でのパニック:
    順序付けられたエクステントの重複、既存の OE file_offset 16384 num_bytes 430080 フラグ0x1089、新しい OE file_offset 16384 num_bytes 430080 フラグ0x80(errno=-17 Object alrea[ 179.162726][ T6897] BTRFS 重要度最高(device loop4):insert_ordered_extent:264 におけるパニック:順序付けられたエクステントの重複、既存の OE file_offset 16384 num_bytes 430080 フラグ0x1089、新しい OE file_offset 16384 num_bytes 430080 フラグ0x80(errno=-17 オブジェクトはすでに存在します) ------------[ cut here ]------------fs/btrfs/ordered-data のカーネルバグ。c:264! ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 05/09/2026 RIP:
    0010:btrfs_alloc_ordered_extent+0x943/0xad0コールトレース: <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 0000000000000000000 ]--- [CAUSE] ff66fe666233(btrfs:追加の直接書き込みに対する不適切なバッファ付き IO フォールバックを修正)をコミットするため、直接 IO がショートに終了した場合は、isize を元のものに戻します。これにより、バッファされたフォールバック中に付加の書き込みが尊重されるようになります。通常、バッファされたライトバックの間、lock_and_cleanup_extent_if_need()関数に依存して、既存の順序付けられたエクステントを待機します。ただし、この順序付けられたエクステント待機は、start_posが isize 内にある場合にのみ発生します。ダイレクト IO の失敗中に isize を元に戻したため、順序付けられたエクステントを待機しません。これは、ダイレクトIO OEがまだツリーにあり、終了してもまだ削除されていない状態で、バッファされた書き込みにOEを挿入して、上記のクラッシュを引き起こす可能性があることを意味します。[修正]戻された isize の状況を処理するために、OE が無条件になるまで待機状態にします。また、lock_and_cleanup_extent_if_need() は今ではエクステントをロックするか、-EAGAIN を返すため、エクステントロックされていないケースを処理するブランチも削除し、名前を変更して _if_need サフィックスを削除します。次のマイクロベンチマークは、「xfs_io -f -c pwrite 0 1m」ワークロードを実行する btrfs_buffered_write() のランタイムの違いを示しており、すべての値はナノ秒単位の平均ランタイムです。関数ランタイム |前 |後
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2 | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3 btrfs_buffered_write()の全体的なランタイムはまだかなり小さい(まだ3マイクロ秒未満)、追加コストはまだ許容できると思います。この問題を修正する代替手段は、isize の戻しが行われる iomap_end() 中に、順序付けられたエクステントを待機することです。しかし、このソリューションは、nowait の要件を破ります。nowait のダイレクト IO がショートに終了した場合、無条件で OE を待機しない必要があり、さもなければバッファされた次の IO が同じ問題に遭遇する可能性もあります。したがって、ここでは待機コストをバッファ付き書き込みに移動する必要がありますが、少なくともコードはもう少し合理化されています。(CVE-2026-90264)

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

The remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4904 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4904-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     November 13, 2026                             https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.115-2~deb12u1     CVE ID         : CVE-2024-58074 CVE-2025-22109 CVE-2025-23132 CVE-2025-23135                      CVE-2025-37743 CVE-2025-37746 CVE-2025-37906 CVE-2025-38029                      CVE-2025-38041 CVE-2025-38042 CVE-2025-38064 CVE-2025-38132                      CVE-2025-38137 CVE-2025-38140 CVE-2025-38187 CVE-2025-38199                      CVE-2025-38207 CVE-2025-38261 CVE-2025-38284 CVE-2025-38359                      CVE-2025-38421 CVE-2025-38597 CVE-2025-38605 CVE-2025-38636                      CVE-2025-38656 CVE-2025-39677 CVE-2025-39775 CVE-2025-39789                      CVE-2025-39830 CVE-2025-39834 CVE-2025-39859 CVE-2025-39862                      CVE-2025-39910 CVE-2025-39933 CVE-2025-39958 CVE-2025-40065                      CVE-2025-40086 CVE-2025-40113 CVE-2025-40130 CVE-2025-40136                      CVE-2025-40338 CVE-2025-40355 CVE-2025-68174 CVE-2025-68193                      CVE-2025-68209 CVE-2025-68236 CVE-2025-68318 CVE-2025-68319                      CVE-2025-68353 CVE-2025-68359 CVE-2025-68360 CVE-2025-68368                      CVE-2025-68376 CVE-2025-68729 CVE-2025-68730 CVE-2025-68735                      CVE-2025-68745 CVE-2025-68755 CVE-2025-71074 CVE-2025-71141                      CVE-2025-71227 CVE-2025-71285 CVE-2025-71313 CVE-2026-23007                      CVE-2026-23017 CVE-2026-23143 CVE-2026-23208 CVE-2026-23217                      CVE-2026-23259 CVE-2026-23327 CVE-2026-23371 CVE-2026-23377                      CVE-2026-23385 CVE-2026-23472 CVE-2026-31493 CVE-2026-31526                      CVE-2026-31562 CVE-2026-31579 CVE-2026-31592 CVE-2026-31630                      CVE-2026-31771 CVE-2026-43009 CVE-2026-43022 CVE-2026-43034                      CVE-2026-43042 CVE-2026-43048 CVE-2026-43053 CVE-2026-43083                      CVE-2026-43101 CVE-2026-43118 CVE-2026-43127 CVE-2026-43172                      CVE-2026-43185 CVE-2026-43191 CVE-2026-43204 CVE-2026-43213                      CVE-2026-43234 CVE-2026-43263 CVE-2026-43272 CVE-2026-43294                      CVE-2026-43298 CVE-2026-43299 CVE-2026-43308 CVE-2026-43309                      CVE-2026-43310 CVE-2026-43311 CVE-2026-43325 CVE-2026-43337                      CVE-2026-43346 CVE-2026-43352 CVE-2026-43353 CVE-2026-43414                      CVE-2026-43443 CVE-2026-43463 CVE-2026-43464 CVE-2026-43465                      CVE-2026-43485 CVE-2026-45932 CVE-2026-45934 CVE-2026-45940                      CVE-2026-45956 CVE-2026-45961 CVE-2026-46014 CVE-2026-46032                      CVE-2026-46044 CVE-2026-46059 CVE-2026-46066 CVE-2026-46071                      CVE-2026-46130 CVE-2026-46148 CVE-2026-46171 CVE-2026-46175                      CVE-2026-46181 CVE-2026-46228 CVE-2026-46245 CVE-2026-46256                      CVE-2026-46272 CVE-2026-46302 CVE-2026-46324 CVE-2026-46325                      CVE-2026-46330 CVE-2026-52937 CVE-2026-52956 CVE-2026-52983                      CVE-2026-52991 CVE-2026-53000 CVE-2026-53009 CVE-2026-53017                      CVE-2026-53018 CVE-2026-53024 CVE-2026-53025 CVE-2026-53091                      CVE-2026-53103 CVE-2026-53104 CVE-2026-53108 CVE-2026-53109                      CVE-2026-53118 CVE-2026-53178 CVE-2026-53224 CVE-2026-53258                      CVE-2026-53277 CVE-2026-53281 CVE-2026-53284 CVE-2026-53285                      CVE-2026-53292 CVE-2026-53297 CVE-2026-53321 CVE-2026-53330                      CVE-2026-53368 CVE-2026-53377 CVE-2026-53401 CVE-2026-63811                      CVE-2026-63825 CVE-2026-63832 CVE-2026-63853 CVE-2026-63857                      CVE-2026-63859 CVE-2026-63879 CVE-2026-63979 CVE-2026-63998                      CVE-2026-63999 CVE-2026-64006 CVE-2026-64024 CVE-2026-64036                      CVE-2026-64038 CVE-2026-64060 CVE-2026-64068 CVE-2026-64076                      CVE-2026-64077 CVE-2026-64079 CVE-2026-64117 CVE-2026-64146                      CVE-2026-64154 CVE-2026-64159 CVE-2026-64190 CVE-2026-64213                      CVE-2026-64283 CVE-2026-64388 CVE-2026-64389 CVE-2026-64400                      CVE-2026-64513 CVE-2026-68081 CVE-2026-68105 CVE-2026-68211                      CVE-2026-68233 CVE-2026-68238 CVE-2026-68241 CVE-2026-68242                      CVE-2026-68258 CVE-2026-68291 CVE-2026-68295 CVE-2026-68312                      CVE-2026-68323 CVE-2026-68375 CVE-2026-68383 CVE-2026-68393                      CVE-2026-68399 CVE-2026-68400 CVE-2026-68401 CVE-2026-68404                      CVE-2026-68409 CVE-2026-68412 CVE-2026-68418 CVE-2026-68421                      CVE-2026-68426 CVE-2026-68435 CVE-2026-68436 CVE-2026-68441                      CVE-2026-68447 CVE-2026-68448 CVE-2026-68453 CVE-2026-68470                      CVE-2026-68471 CVE-2026-72009 CVE-2026-72031 CVE-2026-72073                      CVE-2026-72098 CVE-2026-72162 CVE-2026-72288 CVE-2026-72321                      CVE-2026-72329 CVE-2026-72337 CVE-2026-72341 CVE-2026-72366                      CVE-2026-72367 CVE-2026-72375 CVE-2026-72380 CVE-2026-72383                      CVE-2026-72388 CVE-2026-72397 CVE-2026-72398 CVE-2026-72404                      CVE-2026-72423 CVE-2026-72439 CVE-2026-72440 CVE-2026-72488                      CVE-2026-72493 CVE-2026-72494 CVE-2026-72495 CVE-2026-72497                      CVE-2026-72499 CVE-2026-72500 CVE-2026-72501 CVE-2026-74257                      CVE-2026-74261 CVE-2026-74264 CVE-2026-74269 CVE-2026-74272                      CVE-2026-74273 CVE-2026-74317 CVE-2026-74338 CVE-2026-74344                      CVE-2026-74350 CVE-2026-74368 CVE-2026-74373 CVE-2026-74374                      CVE-2026-74375 CVE-2026-74385 CVE-2026-74388 CVE-2026-74405                      CVE-2026-74407 CVE-2026-74449 CVE-2026-74466 CVE-2026-74506                      CVE-2026-74513 CVE-2026-74520 CVE-2026-74527 CVE-2026-74529                      CVE-2026-74530 CVE-2026-74533 CVE-2026-74537 CVE-2026-74538                      CVE-2026-74542 CVE-2026-74544 CVE-2026-74558 CVE-2026-74559                      CVE-2026-74571 CVE-2026-74600 CVE-2026-74605 CVE-2026-74611                      CVE-2026-74687 CVE-2026-74690 CVE-2026-74695 CVE-2026-74697                      CVE-2026-74711 CVE-2026-74713 CVE-2026-74715 CVE-2026-74723                      CVE-2026-74728 CVE-2026-74729 CVE-2026-74733 CVE-2026-74734                      CVE-2026-74747 CVE-2026-74752 CVE-2026-74754 CVE-2026-80581                      CVE-2026-80607 CVE-2026-80614 CVE-2026-80616 CVE-2026-80623                      CVE-2026-80628 CVE-2026-80631 CVE-2026-80634 CVE-2026-80643                      CVE-2026-80653 CVE-2026-80655 CVE-2026-80662 CVE-2026-80668                      CVE-2026-80692 CVE-2026-80693 CVE-2026-80698 CVE-2026-80705                      CVE-2026-80734 CVE-2026-80738 CVE-2026-80747 CVE-2026-80761                      CVE-2026-80786 CVE-2026-80866 CVE-2026-80884 CVE-2026-80905                      CVE-2026-80920 CVE-2026-80948 CVE-2026-89528 CVE-2026-89534                      CVE-2026-89537 CVE-2026-89601 CVE-2026-89631 CVE-2026-89642                      CVE-2026-89648 CVE-2026-89654 CVE-2026-89682 CVE-2026-89705                      CVE-2026-89709 CVE-2026-89757 CVE-2026-89788 CVE-2026-89808                      CVE-2026-89810 CVE-2026-89811 CVE-2026-89812 CVE-2026-89813                      CVE-2026-89833 CVE-2026-89906 CVE-2026-89913 CVE-2026-89920                      CVE-2026-89987 CVE-2026-90061 CVE-2026-90083 CVE-2026-90084                      CVE-2026-90086 CVE-2026-90087 CVE-2026-90093 CVE-2026-90097                      CVE-2026-90099 CVE-2026-90104 CVE-2026-90105 CVE-2026-90106                      CVE-2026-90111 CVE-2026-90116 CVE-2026-90142 CVE-2026-90144                      CVE-2026-90149 CVE-2026-90154 CVE-2026-90155 CVE-2026-90156                      CVE-2026-90161 CVE-2026-90162 CVE-2026-90167 CVE-2026-90174                      CVE-2026-90177 CVE-2026-90179 CVE-2026-90182 CVE-2026-90183                      CVE-2026-90204 CVE-2026-90205 CVE-2026-90206 CVE-2026-90208                      CVE-2026-90217 CVE-2026-90231 CVE-2026-90232 CVE-2026-90234                      CVE-2026-90240 CVE-2026-90247 CVE-2026-90256 CVE-2026-90259                      CVE-2026-90260 CVE-2026-90263 CVE-2026-90264 CVE-2026-90265                      CVE-2026-90267 CVE-2026-90273 CVE-2026-90289 CVE-2026-90300                      CVE-2026-90301 CVE-2026-90311 CVE-2026-90320 CVE-2026-90321                      CVE-2026-90324 CVE-2026-90326 CVE-2026-90328 CVE-2026-90330                      CVE-2026-90333 CVE-2026-90335 CVE-2026-90336 CVE-2026-90337                      CVE-2026-90343 CVE-2026-90345 CVE-2026-90346 CVE-2026-90347                      CVE-2026-90351 CVE-2026-90359 CVE-2026-90363 CVE-2026-90365                      CVE-2026-90367 CVE-2026-90408 CVE-2026-90409 CVE-2026-90417                      CVE-2026-90421 CVE-2026-90422 CVE-2026-90424 CVE-2026-90427                      CVE-2026-92480 CVE-2026-92482 CVE-2026-92485 CVE-2026-92503                      CVE-2026-92520 CVE-2026-93058 CVE-2026-93081 CVE-2026-93100                      CVE-2026-93104 CVE-2026-93105 CVE-2026-93116 CVE-2026-93122                      CVE-2026-93125 CVE-2026-93129 CVE-2026-93144 CVE-2026-93146                      CVE-2026-93148 CVE-2026-93168 CVE-2026-93175 CVE-2026-93176                      CVE-2026-93181 CVE-2026-93202 CVE-2026-93216 CVE-2026-93221                      CVE-2026-93230 CVE-2026-93251 CVE-2026-93260 CVE-2026-93272                      CVE-2026-93282 CVE-2026-97422 CVE-2026-97424 CVE-2026-97432                      CVE-2026-97477 CVE-2026-97478 CVE-2026-97479 CVE-2026-97480                      CVE-2026-97493 CVE-2026-97501 CVE-2026-97503 CVE-2026-97513                      CVE-2026-97515 CVE-2026-97538 CVE-2026-97554 CVE-2026-97561                      CVE-2026-97928 CVE-2026-97960 CVE-2026-97962 CVE-2026-97975                      CVE-2026-97988 CVE-2026-97989 CVE-2026-97997 CVE-2026-98003                      CVE-2026-98019 CVE-2026-98032 CVE-2026-98033 CVE-2026-98034                      CVE-2026-98038 CVE-2026-98043 CVE-2026-98044 CVE-2026-98047                      CVE-2026-98048 CVE-2026-98049 CVE-2026-98053 CVE-2026-98058                      CVE-2026-98062 CVE-2026-98067 CVE-2026-98073 CVE-2026-98079                      CVE-2026-98084 CVE-2026-98085 CVE-2026-98099 CVE-2026-98124                      CVE-2026-98131 CVE-2026-98134 CVE-2026-98147 CVE-2026-98148                      CVE-2026-98156 CVE-2026-98916 CVE-2026-98974 CVE-2026-98975                      CVE-2026-98977 CVE-2026-98981 CVE-2026-98985 CVE-2026-98993                      CVE-2026-99002 CVE-2026-99009 CVE-2026-99014 CVE-2026-99019                      CVE-2026-99027 CVE-2026-99028 CVE-2026-99041 CVE-2026-99044                      CVE-2026-99077 CVE-2026-99082 CVE-2026-99083 CVE-2026-99085                      CVE-2026-99092 CVE-2026-99098 CVE-2026-99100 CVE-2026-99103                      CVE-2026-99105 CVE-2026-99106 CVE-2026-99110 CVE-2026-99112                      CVE-2026-99113 CVE-2026-99114 CVE-2026-99115 CVE-2026-99117                      CVE-2026-99118 CVE-2026-99121 CVE-2026-99123 CVE-2026-99124                      CVE-2026-99126 CVE-2026-99127 CVE-2026-99128 CVE-2026-99130                      CVE-2026-99131 CVE-2026-99132 CVE-2026-99133 CVE-2026-99134                      CVE-2026-99135 CVE-2026-99136 CVE-2026-99138 CVE-2026-99139                      CVE-2026-99140 CVE-2026-99142 CVE-2026-99143 CVE-2026-99147                      CVE-2026-99150 CVE-2026-99152 CVE-2026-99153 CVE-2026-99154                      CVE-2026-99155 CVE-2026-99156 CVE-2026-99157 CVE-2026-99158                      CVE-2026-99159 CVE-2026-99160 CVE-2026-99161 CVE-2026-99163                      CVE-2026-99165 CVE-2026-99166 CVE-2026-99167 CVE-2026-99169                      CVE-2026-99171 CVE-2026-99173 CVE-2026-99174 CVE-2026-99175                      CVE-2026-99176 CVE-2026-99178 CVE-2026-99179 CVE-2026-99180                      CVE-2026-99181 CVE-2026-99182 CVE-2026-99187 CVE-2026-99191                      CVE-2026-99192 CVE-2026-99201 CVE-2026-99202 CVE-2026-99203                      CVE-2026-99204 CVE-2026-99206 CVE-2026-99211 CVE-2026-99212                      CVE-2026-99213 CVE-2026-99214 CVE-2026-99216 CVE-2026-99218                      CVE-2026-99219 CVE-2026-99220 CVE-2026-99221 CVE-2026-99222                      CVE-2026-99223 CVE-2026-99224 CVE-2026-99225 CVE-2026-99226                      CVE-2026-99227 CVE-2026-99228 CVE-2026-99229 CVE-2026-99230                      CVE-2026-99231 CVE-2026-99233 CVE-2026-99234 CVE-2026-99235                      CVE-2026-99236 CVE-2026-99239 CVE-2026-99244 CVE-2026-99245                      CVE-2026-99246 CVE-2026-99247 CVE-2026-99249 CVE-2026-99250                      CVE-2026-99251 CVE-2026-99254 CVE-2026-99255 CVE-2026-99256                      CVE-2026-99258 CVE-2026-99284 CVE-2026-99285 CVE-2026-100072                      CVE-2026-100074 CVE-2026-100076 CVE-2026-100077     Debian Bug     : 1112238 1151097 1151281

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 12 bookworm, these problems have been fixed in version     6.12.115-2~deb12u1.  This update additionally includes many more bug     fixes from stable updates 6.12.114 and 6.12.115.

    We recommend that you upgrade your linux-6.12 packages.

    For the detailed security status of linux-6.12 please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux-6.12

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian security advisory.

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.

  - btrfs: always wait for ordered extents to avoid OE races [BUG] Syzbot reported a bug that there can be     conflicting OEs for the same range: BTRFS critical (device loop4): panic in insert_ordered_extent:264:
    overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe     file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical     (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset     16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17     Object already exists) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:264!     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 RIP:
    0010:btrfs_alloc_ordered_extent+0x943/0xad0 Call Trace: <TASK> cow_file_range+0x744/0x12a0     fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20     writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560     filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30     btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 0000000000000000 ]--- [CAUSE] Since commit ff66fe666233 (btrfs: fix incorrect buffered IO     fallback for append direct writes), if the direct IO finished short, we will revert the isize back to the     original one, so that append writes can be respected during the buffered fallback. Normally we rely on     lock_and_cleanup_extent_if_need() function during buffered writeback to wait for any existing ordered     extents. But that ordered extent waiting only happens if the start_pos is inside the isize. Since we have     reverted the isize during failed direct IO, we will not wait for any ordered extents. This means we can     have a race where the direct IO OE is still in the tree, finished but not yet removed, then we're     inserting the OE for the buffered write, causing the above crash. [FIX] Make the OE wait to be     unconditional, to handle the reverted isize situation. And since lock_and_cleanup_extent_if_need() now     either lock the extents or return -EAGAIN, also remove the branches that handles no-extent-locked cases,     and rename it to remove the _if_need suffix. The following micro benchmark shows the runtime difference     for btrfs_buffered_write(), doing `xfs_io -f -c pwrite 0 1m` workload, all values are the average     runtime in nano seconds. function runtime | before | after
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2     | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3 The overall runtime of btrfs_buffered_write() is still     pretty tiny (still less than 3 micro seconds), I'd say the extra cost is still acceptable. An alternative     to fix this problem is to wait ordered extents during iomap_end() where the isize revert is done. But that     solution will break nowait requirement, as if a nowait direct IO finished short, we have to wait for the     OEs unconditionally or the next append buffered IO can still hit the same problem. So here we have to move     the wait cost to buffered write, but at least the code is slightly more streamline. (CVE-2026-90264)

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

ID	Name	Product	Family	Published	Updated	Severity
347831	Linux Distros 未修補弱點：CVE-2026-90264	Nessus	Misc.	9/18/2026	11/11/2026	medium
365258	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	10/12/2026	10/29/2026	high
365258	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	10/12/2026	10/29/2026	high
347831	Linux Distros 未修补的漏洞：CVE-2026-90264	Nessus	Misc.	9/18/2026	11/11/2026	medium
347831	Linux Distros のパッチ未適用の脆弱性: CVE-2026-90264	Nessus	Misc.	9/18/2026	11/11/2026	medium
365258	Amazon Linux 2023 : bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	10/12/2026	10/29/2026	high
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	11/5/2026	11/5/2026	high
380301	Debian dla-4904 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	11/13/2026	11/13/2026	high
347831	Linux Distros Unpatched Vulnerability : CVE-2026-90264	Nessus	Misc.	9/18/2026	11/11/2026	medium
365258	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	10/12/2026	10/29/2026	high
377900	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3402)	Nessus	Amazon Linux Local Security Checks	11/9/2026	11/11/2026	high

Detections

Analytics

Plugins Search

medium

high

high

medium

medium

high

high

high

medium

high

high