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

  - xfs:リーフブロックに xattrs を追加する際の freemap 調整を修正します xfs/592 と xfs/794 はどちらも、私のテスト VM で ~20 分実行した後に、リーフブロックの freemap 調整コードでこのアサーションをトリップさせます:
    ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));
    さらに多くのデバッグコードを有効にした後、これを namelen=3 と valuelen=71 のローカル拡張属性を設定しようとしている fsstress に絞り込みました。このため、エントリサイズは 80 バイトになります。xfs_attr3_leaf_add_workの先頭では、フリーマップは次のようになります: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 ここで、rhs はリーフエントリ配列の末尾を過ぎた最初のバイトです。これは矛盾しています -- エントリ配列はバイト 448 で終わりますが、freemap[1] は、バイト 388 から始まる空き領域があると言います。関数の終わりまでに、フリーマップの状態は悪化します: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 重要な注意: 388 は、エントリの配列要素サイズの 8 バイトに整列されていません。正しくないフリーマップに基づくと、名前領域はバイト 440 から始まり、エントリ配列の終わりより下です。そのため、アサーションがトリガーされ、ファイルシステムがシャットダウンされます。どうしてここまで来たのでしょうか? まず、以前のパッチで、xattr リーフブロックのフリーマップ配列は、リーフブロック内のすべての空き領域の包括的なマップになることを意図したものではないことを思い出してください。言い換えれば、以下のリーフブロックを持つことは完全に合法です:* 376バイトがエントリ配列によって使用されています * freemap[0] は [base = 376, size = 8] を持っています * freemap[1] は [base = 388, size = 1500] * 376 と 388 の間のスペースは空いていますが、freemap が少し前に追跡を停止しました xattr を 1 つ追加すると、 エントリ配列は 384 バイトに成長し、freemap[0] は [base = 384, size = 0] になります。ここまでは順調です。しかし、2番目のxattrを追加すると、エントリ配列は392バイトに増加し、freemap[0]は[base = 392, size = 0]にプッシュアップされます。freemap[1] が更新されておらず、エントリ配列と空き領域が同じスペースを要求するようになったため、これは悪いことです。ここでの修正は、すべてのフリーマップエントリを調整して、いずれもエントリ配列と衝突しないようにすることです。注意:この修正は、コミット 2a2b5932db6758(xfs:属性リーフヘッダーの freemap.size アンダーフローを修正)およびゼロレングスのフリーマップエントリを base = 0 にリセットする以前のパッチに依存します。(CVE-2026-43158)

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

検出

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

high Nessus プラグイン ID 312772

バージョン 1.20