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 Distros 未修補弱點：CVE-2024-14040

high Nessus Plugin ID 330018

版本 1.5