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 Distros 未修补的漏洞：CVE-2024-14040

medium Nessus 插件 ID 330018

版本 1.1