Vulnerabilidad en Linux (CVE-2024-14040)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: nexthop: Aumentar el peso a u16<br /> <br /> En las redes CLOS, a medida que ocurren fallos de enlace en varios puntos de la red, los pesos ECMP de los nodos involucrados se ajustan para compensar. Con una alta ramificación de los nodos involucrados y un número total elevado de nodos, una relación de peso (no-)ECMP que nos gustaría configurar no cabe en 8 bits. En lugar de, digamos, 255:254, podríamos querer configurar algo como 1000:999. Para estas implementaciones, el peso de 8 bits podría no ser suficiente.<br /> <br /> Con ese fin, en este parche se aumenta el peso del siguiente salto de u8 a u16.<br /> <br /> Aumentar el ancho de un tipo integral puede ser complicado, porque si bien el código aún compila, los tipos podrían ya no coincidir y surgen errores numéricos. Para evitar esto, la conversión se realizó en dos pasos. Primero, el tipo se cambió de u8 a una estructura de un solo miembro, lo que invalidó todos los usos del campo. Esto permitió revisarlos uno por uno y auditar la corrección del tipo. Luego, la estructura fue reemplazada por un u16 estándar nuevamente. Esto debería asegurar que no se omitió ningún lugar.<br /> <br /> La UAPI para configurar los miembros del grupo nexthop es que un atributo NHA_GROUP lleva un array de entradas de struct nexthop_grp:<br /> <br /> struct nexthop_grp {<br /> __u32 id; /* id de nexthop - debe existir */<br /> __u8 weight; /* peso de este nexthop */<br /> __u8 resvd1;<br /> __u16 resvd2;<br /> };<br /> <br /> El campo resvd1 está actualmente validado y se requiere que sea cero. Podemos levantar este requisito y llevar los bits de orden superior del peso en el campo reservado:<br /> <br /> struct nexthop_grp {<br /> __u32 id; /* id de nexthop - debe existir */<br /> __u8 weight; /* peso de este nexthop */<br /> __u8 weight_high;<br /> __u16 resvd2;<br /> };<br /> <br /> Se eligió mantener los campos divididos de esta manera en caso de que un userspace existente haga suposiciones sobre el ancho del campo de peso, y para evitar cualquier problema de endianness.<br /> <br /> El campo de peso está actualmente codificado como el valor del peso menos uno, porque un peso de 0 es inválido. Este mismo truco es imposible para el nuevo campo weight_high, porque cero debe significar cero real. Con esto implementado:<br /> <br /> - Se garantiza que el userspace antiguo llevará un weight_high de 0, por lo tanto, configurando pesos de 8 bits según corresponda. Al volcar nexthops con peso de 16 bits, solo mostraría los 8 bits inferiores. Pero configurar tales nexthops implica la existencia de un userspace consciente de la extensión en primer lugar.<br /> <br /> - El nuevo userspace que se comunica con un kernel antiguo funcionará siempre y cuando solo intente configurar pesos de 8 bits, donde los bits de orden superior son cero. El kernel antiguo rechazará los intentos de configurar pesos &gt;8 bits.<br /> <br /> Renombrar campos reservados a medida que se asignan para algún propósito es algo común en Linux. Quien toque un campo reservado lo hace bajo su propio riesgo. nexthop_grp::resvd1 en particular es actualmente utilizado por al menos strace, sin embargo, llevan una copia propia de los encabezados UAPI, y la conversión debería ser trivial. Se proporciona una función de ayuda para decodificar el peso de los dos campos. Forzar una conversión parece preferible a hacer malabares e introducir uniones anónimas o lo que sea.