Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - net：nexthop：增加權重至 u16 在 CLOS 網路中，當網路中的各個點發生鏈路故障時，會調整相關節點的 ECMP 權重以進行補償。由於相關節點的扇出率很高，而且節點數量總數較多，因此我們想要設定的 （非） ECMP 權重比不適合 8 位元。我們可能想要配置類似 1000:999的 ，而不是 255:254。對於這些部署，8 位元權重可能不夠。為此，在此補丁中，將下一跳權重從 u8 增加到 u16。增加整數類型的寬度可能很棘手，因為當程式碼仍在編譯時，類型可能不再簽出，並且會出現數值錯誤。為了防止這種情況發生，轉換分兩個步驟完成。首先，類型從 u8 更改為單成員結構，這使得該字段的所有用途都無效。這允許逐一檢查它們並審核類型正確性。然後該結構再次被香草 u16 取代。這應該確保不會錯過任何位置。用於設定 nexthop 群組成員的 UAPI 是屬性NHA_GROUP攜帶結構nexthop_grp項目陣列： struct nexthop_grp { __u32 id; /* nexthop id - 必須存在 */ __u8權重;
    /* 此 nexthop 的權重 */ __u8 resvd1;__u16 resvd2;};欄位 resvd1 目前已驗證，且必須為零。我們可以提升此要求，並在保留欄位中攜帶權重的高階位元： struct nexthop_grp { __u32 id; /* nexthop id - 必須存在 */ __u8權重; /* 此 nexthop 的權重
    */ __u8 weight_high;__u16 resvd2;};選擇以這種方式分割欄位是為了防止現有使用者空間對權重欄位的寬度做出假設，並避免任何字節碼問題。
    權重欄位目前編碼為權重值減一，因為權重 0 無效。同樣的技巧對於新的weight_high場來說是不可能的，因為零必須意味著實際的零。有了這個： - 保證舊使用者空間承載 0 的weight_high，因此請視需要配置 8 位元權重。轉儲具有 16 位權重的 nexthop 時，它只會顯示較低的 8 位。但配置此類 nexthop 意味著首先存在意識到擴展的用戶空間。- 只要新使用者空間僅嘗試設定 8 位元權重（其中高階位元為零），即可與舊核心通訊。舊核心會退回設定 >8 位元權重的嘗試。在 Linux 中，通常會在為某些目的分配保留欄位時重新命名保留欄位。任何接觸保留場地的人都將自行承擔風險。特別是 nexthop_grp：：resvd1 目前至少由 strace 使用，但是它們帶有自己的 UAPI 標頭副本，並且轉換應該是微不足道的。提供了一個輔助程式來解碼兩個字段的權重。強制轉換似乎比向後彎曲並引入匿名聯合或其他什麼更可取。（CVE-2024-14040）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - net：nexthop：将权重增加到 u16 在 CLOS 网络中，当网络中的各个点发生链路故障时，会调整相关节点的 ECMP 权重以进行补偿。由于涉及的节点扇出率高，并且节点总数较多，我们想要配置的（非）ECMP 权重比不适合 8 位。而不是，比如说， 255:254我们可能想要配置类似 1000:999的东西。对于这些部署，8 位的权重可能不够。为此，在此修补程序中，下一个跃点权重从 u8 增加到 u16。增加整数类型的宽度可能很棘手，因为虽然代码仍在编译，但类型可能不再检出，并且会出现数值错误。为了防止这种情况，转换分两步完成。首先，将类型从 u8 更改为单成员结构，这使该字段的所有使用无效。这允许逐一检查它们并审核类型正确性。然后该结构再次被普通 u16 取代。这应确保不会遗漏任何位置。配置 nexthop 组成员的 UAPI 是属性NHA_GROUP携带 struct nexthop_grp 条目数组： struct nexthop_grp { __u32 id; /* nexthop id - 必须存在 */ __u8权重;
    /* 此 nexthop 的权重 */ __u8 resvd1;__u16 resvd2;};字段 resvd1 目前已经过验证，要求为零。我们可以提升此要求并在保留字段中携带权重的高位： struct nexthop_grp { __u32 id; /* nexthop id - 必须存在 */ __u8 weight; /* 此 nexthop 的权重
    */ __u8 weight_high;__u16 resvd2;};选择保持此方式拆分字段是为了防止现有用户空间对权重字段的宽度进行假设，并避免任何字节顺序问题。
    权重字段当前编码为权重值减一，因为权重 0 无效。对于新的weight_high字段来说，同样的技巧是不可能的，因为零必须意味着实际的零。具备以下条件之后：- 保证旧用户空间的weight_high为 0，因此请酌情配置 8 位权重。转储具有 16 位权重的 nexthops 时，仅显示较低的 8 位。但配置此类 nexthops 意味着存在第一个可识别扩展的用户空间。- 只要新用户空间仅尝试配置 8 位权重（其中高阶位为零），它就可以与旧内核通信。旧内核会反弹配置 >8 位权重的尝试。Linux 中通常会在为某种目的分配保留的字段时对其进行重命名。任何接触保留场地的人都将自行承担风险。特别是 nexthop_grp：：resvd1 目前至少被 strace 使用，不过它们带有自己的 UAPI 标头副本，并且转换应该很简单。提供了一个帮助程序，用于解码两个字段的权重。强制转换似乎比向后弯曲并引入匿名联合或其他什么更可取。（CVE-2024-14040）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

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 は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - net: nexthop: Increase weight to u16 In CLOS networks, as link failures occur at various points in the     network, ECMP weights of the involved nodes are adjusted to compensate. With high fan-out of the involved     nodes, and overall high number of nodes, a (non-)ECMP weight ratio that we would like to configure does     not fit into 8 bits. Instead of, say, 255:254, we might like to configure something like 1000:999. For     these deployments, the 8-bit weight may not be enough. To that end, in this patch increase the next hop     weight from u8 to u16. Increasing the width of an integral type can be tricky, because while the code     still compiles, the types may not check out anymore, and numerical errors come up. To prevent this, the     conversion was done in two steps. First the type was changed from u8 to a single-member structure, which     invalidated all uses of the field. This allowed going through them one by one and audit for type     correctness. Then the structure was replaced with a vanilla u16 again. This should ensure that no place     was missed. The UAPI for configuring nexthop group members is that an attribute NHA_GROUP carries an array     of struct nexthop_grp entries: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight;
    /* weight of this nexthop */ __u8 resvd1; __u16 resvd2; }; The field resvd1 is currently validated and     required to be zero. We can lift this requirement and carry high-order bits of the weight in the reserved     field: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop
    */ __u8 weight_high; __u16 resvd2; }; Keeping the fields split this way was chosen in case an existing     userspace makes assumptions about the width of the weight field, and to sidestep any endianness issues.
    The weight field is currently encoded as the weight value minus one, because weight of 0 is invalid. This     same trick is impossible for the new weight_high field, because zero must mean actual zero. With this in     place: - Old userspace is guaranteed to carry weight_high of 0, therefore configuring 8-bit weights as     appropriate. When dumping nexthops with 16-bit weight, it would only show the lower 8 bits. But     configuring such nexthops implies existence of userspace aware of the extension in the first place. - New     userspace talking to an old kernel will work as long as it only attempts to configure 8-bit weights, where     the high-order bits are zero. Old kernel will bounce attempts at configuring >8-bit weights. Renaming     reserved fields as they are allocated for some purpose is commonly done in Linux. Whoever touches a     reserved field is doing so at their own risk. nexthop_grp::resvd1 in particular is currently used by at     least strace, however they carry an own copy of UAPI headers, and the conversion should be trivial. A     helper is provided for decoding the weight out of the two fields. Forcing a conversion seems preferable to     bending backwards and introducing anonymous unions or whatever. (CVE-2024-14040)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
330018	Linux Distros 未修補弱點：CVE-2024-14040	Nessus	Misc.	7/26/2026	8/27/2026	high
330018	Linux Distros 未修补的漏洞：CVE-2024-14040	Nessus	Misc.	7/26/2026	8/27/2026	high
330018	Linux Distros のパッチ未適用の脆弱性: CVE-2024-14040	Nessus	Misc.	7/26/2026	8/27/2026	high
330018	Linux Distros Unpatched Vulnerability : CVE-2024-14040	Nessus	Misc.	7/26/2026	8/27/2026	high

Detections

Analytics

Plugins Search

high

high

high

high