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

  - batman-adv:bla:パラレルクレームによる CRC 破損を回避します batadv_bla_add_claim() は、リモートバックボーンとローカルパケットからクレームを追加し、クレームのバックボーンを修正するために使用されます。クレームを処理するとき、 * 新しいクレームの CRC をバックボーン CRC に追加 * 既存のクレームの CRC を古いバックボーンから削除し、新しいバックボーンに追加する必要があります。ただし、新しいクレームコードが変更バックボーンコードと並行して実行されている場合は、新しいクレームコードパスでクレームのbackbone_gwが 2 回変更されているために CRC が無効になることがあります。 * CPU0 がゲートウェイ A のクレームを作成し、クレームハッシュでこれを公開します。現時点では、アドレスの crc16 は A の crc にまだ追加されていません。* CPU1 は、同じクライアントのためのゲートウェイ B のクレームフレームを処理し、パブリッシュされたばかりのクレームを見つけ、所有権の変更を行います。ポインターを B に切り替え、A の crc から crc16(含まれていないもの)を削除し、それを B の crc に追加します。* CPU0 は作成ブランチの背後に進み、B の crc を補償することなく無条件にポインターを A に戻し(作成パスに対するポインターのremove_crcは偽です)、最後に crc16 を A の crc に追加します。この場合、CRC は両方に対して間違っています: * クレームは A に属していますが、CRC はバックボーン A の CRC の一部ではありません * クレームは B に属していません: CRC は依然としてバックボーン B の CRC の一部です この間違った CRC は、保存されたクレームから再計算されることはありません。ローカルバックボーンクレームの場合、これも同期を使用して回復できません。これを回避するには、各機能を明確で別々の部分に分割します:* 新しいクレームは、クレーム CRC をバックボーン CRC に常に追加します(ただし、すでに設定されたクレームのbackbone_gwは決して変更しません)* 既存のクレームの更新。backbone_gw エントリを自動的に変更し、実際の変更があった場合にのみ両方のバックボーン CRC を更新します(CVE-2026-93203)

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

検出

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

high Nessus プラグイン ID 347529

バージョン 1.7