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

  - ext4残存データによる無限ループを回避。mkdir/mknod パスで、論理ブロックを物理ブロックにマッピングする際、エクステントツリーへの新しいエクステントの挿入が失敗した場合この例ではファイルシステムが huge file 機能を無効にしており、 inode をダーティとしてマーク) を実行する場合、ext4_ext_map_blocks() は ext4_free_blocks() のみを呼び出し、エクステントツリー内の対応するデータを削除せずに物理ブロックを再要求します。これにより、物理ブロックがすでに xattr ブロックにより使用されているにもかかわらず、その後の mkdir 操作で再び以前リクレイムされた物理ブロック番号が再び参照されます。したがって、ディレクトリとxattrの両方がメモリで同じバッファヘッドブロックを同時に使用する状況が発生します。
    上記が原因で、ext4_xattr_block_set() は挿入についての無限ループに陥り、inode ロックを解放できず、最終的に [1] で言及されている 143s ブロック問題につながります。メタデータが破損している場合、一部のエクステント空間を削除しようとすると、さらなる悪影響がさらに及ぶ可能性があります。また、EXT4_GET_BLOCKS_DELALLOC_RESERVE が渡された場合、クォータ情報を間違って更新するためにスペースを削除します。Jan Kara 氏は、次の 2 つのケースを区別することを提案しています 1) エラーは ENOSPC または EDQUOT です - この場合、ファイルシステムは完全に一貫性があり、すべての説明を含めて一貫性を維持する必要があります。しかし、これらのエラーは、エクステントをエクステントツリーに挿入する前の段階でのみ発生する可能性があります。したがって、この場合、現在のコードは正しく動作します。 2) 一部のその他のエラー - メタデータが破損していることを意味します。被害を最小限に抑えるために変更を最小限に抑えるように努力する必要があります。そのため、割り当てられたブロックの解放をスキップします。 [1] 情報
    task syz.0 を実行します。17:5995 143 秒以上ブロックされました。Call Traceinode_lock_nested include/linux/fs.h:1073 [インライン] __start_dirop fs/namei.c:2923 [インライン] start_dirop fs/namei.c:2934 [インライン]CVE-2026-31448]

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

検出

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

critical Nessus プラグイン ID 309696

バージョン 1.20