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

  - net:nexthop:u16 に重みを増やします CLOS ネットワークでは、ネットワークのさまざまなポイントでリンク障害が発生するため、関係するノードの ECMP 重みを調整してそれを補償します。関連するノードのファンアウトが高く、ノード数が全体的に多いため、構成したい(非)ECMP重み比は8ビットに収まりません。たとえば、 255:254 ではなく、 1000:999 のような設定をしたいと思うかもしれません。このようなデプロイメントでは、8 ビットの重みでは不十分な場合があります。そのために、このパッチでネクストホップの重みを u8 から u16 に増やします。整数型の幅を大きくするのは、コードがコンパイルされている間、型がチェックアウトされなくなり、数値エラーが発生する可能性があるため、難しい場合があります。これを防ぐために、変換は 2 つのステップで行われました。まず、タイプが u8 から単一メンバー構造に変更されました。これにより、フィールドの使用はすべて無効になりました。これにより、それらを 1 つずつ確認し、型の正確性を監査することが可能になりました。その後、構造は再びバニラ u16 に置き換えられました。これにより、場所を見逃すことがなくなります。nexthop グループメンバーを構成するための UAPI は、属性NHA_GROUPが構造体nexthop_grpエントリの配列を持っているということです: struct nexthop_grp { __u32 id; /* nexthop id - 存在する必要があります */ __u8 weight;
    /* この nexthop の重み */ __u8 resvd1;__u16 resvd2;};フィールド resvd1 は現在検証されており、ゼロである必要があります。この要件を解除して、予約されたフィールドで重みの上位ビットを運ぶことができます:struct nexthop_grp { __u32 id; /* nexthop id - 存在する必要があります */ __u8重み; /* この nexthop の重み
    */ __u8 weight_high;__u16 resvd2;};既存のユーザー空間が重みフィールドの幅について仮定する場合と、エンディアンの問題を回避するために、この方法でフィールドを分割したままにすることが選択されました。
    重みフィールドは現在、重み値から 1 を引いた値としてエンコードされています。これは重みが 0 の場合無効であるためです。ゼロは実際のゼロを意味するに違いないため、新しいweight_highフィールドではこれと同じトリックは不可能です。これを設定すると、次のようになります。 - 古いユーザー空間は0のweight_highを伝送することが保証されているため、必要に応じて8ビットの重みを構成します。重みが 16 ビットのネクストホップをダンプすると、下位の 8 ビットのみが表示されます。しかし、このようなネクストホップを構成することは、そもそも拡張を認識するユーザー空間の存在を意味します。- 古いカーネルにトークする新しいユーザー空間は、上位ビットがゼロの 8 ビットの重みの構成のみを試みる限り、機能します。古いカーネルは、>8 ビットの重みを設定しようとすると、試行をバウンスします。予約済みフィールドが何らかの目的で割り当てられたときに名前を変更することは、Linuxで一般的に行われます。予約されたフィールドに触れた人は、自己責任でそうすることになります。特に nexthop_grp::resvd1 は少なくとも strace によって現在使用されていますが、UAPI ヘッダーの独自のコピーを運ぶため、変換は軽微なものになるはずです。ヘルパーは、2 つのフィールドから重みをデコードするために提供されています。変換を強制することは、後方に曲がって匿名共用体などを導入するよりも望ましいようです。(CVE-2024-14040)

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

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2024-14040

high Nessus プラグイン ID 330018

バージョン 1.3