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

  - ext4:e4b ビットマップの不一致のレポートを修正します 混合されている巨大なページのワークロードのストレステストで、ビットマップの不一致の問題が観察されました。Ext4 は、次のような複数の e4b ビットマップチェックの失敗を報告しています:
    ext4_mb_complex_scan_group:2508:グループ情報に従ってグループ 350、8179 の解放クラスターをグループ化します。しかし、8192 ブロックを取得しました。分析と実験により、この問題はページ移行とビットマップ変更の間の競合状態によって引き起こされることが確認されました。このタイミングウィンドウは非常に狭いですが、実際には依然としてヒットします。
    folio_lock ext4_mb_load_buddy __migrate_folio 参照カウントfolio_mc_copy __filemap_get_folio folio_try_get(folio)をチェック......mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock この問題の根本的な原因は、load_buddyのファストパスがフォリオの参照カウントを増加させるだけであり、同時フォリオ移行を防ぐには不十分であることです。フォリオ移行プロセスがフォリオロックを取得することを確認しました。したがって、ロック状態を確認することで、load_buddyでファストパスを取るかどうかを判断できます。フォリオがロックされている場合は、この同時実行ウィンドウを閉じるためにスローパス(ロックを取得する)を選択します。さらに、この変更は次の問題に対処します: DOUBLE_CHECKマクロを有効にしてビットマップ関連の問題を調べるとき、次のエラーがトリガーされる場合があります。
    グループ 324 のバイト 784(6272) での破損:disk/prealloc の copy != ff の f 分析により、これが偽陽性であることが明らかになります。特定の競合ウィンドウがあり、ビットマップとグループ記述子が一時的に一致しなくなり、次のエラーレポートにつながります:ext4_mb_load_buddy ext4_mb_load_buddy
    __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ......mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock 元のロジックでは、ビットマップがディスクから新たにロードされたときに mb_cmp_bitmaps が呼び出されるため、フォリオロックで同時アクセスを防ぐのに十分であると想定されていました。ただし、これは特定の競合状態を見落とします:別のプロセスが buddy のロードを試み、Folio がすでに最新の状態にあることが判明した場合、Folio ロックを保持せずにすぐにその使用を開始します。(CVE-2026-45942)

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

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-45942

high Nessus プラグイン ID 317178

バージョン 1.14