CVE-2024-14040

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