CVE-2021-47044

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/fair: corrigió el desplazamiento fuera de los límites en load_balance() Syzbot informó sobre varios casos en los que sd->nr_balance_failed puede crecer a valores mucho más altos de lo que uno esperaría. . Un load_balance() exitoso lo restablece a 0; uno fallido lo incrementa. Una vez que llegue a sd->cache_nice_tries + 3, esto *debería* activar un saldo activo, que lo establecerá en sd->cache_nice_tries+1 o lo restablecerá a 0. Sin embargo, en caso de que el saldo esté activo La tarea no puede ejecutarse en env->dst_cpu, entonces el incremento se realiza sin ninguna modificación adicional. Esto podría repetirse hasta la saciedad y explicaría los valores absurdamente altos informados por syzbot (86, 149). VincentG señaló que es valioso dejar que sd->cache_nice_tries crezca, por lo que el cambio en sí debería corregirse. Eso significa evitar: """ Si el valor del operando derecho es negativo o es mayor o igual que el ancho del operando izquierdo promocionado, el comportamiento no está definido. """ Por lo tanto, debemos limitar el exponente de desplazamiento a BITS_PER_TYPE( typeof(lefthand)) - 1. Eché un vistazo a otros casos similares a través de coccinelle: @expr@ position pos; expresión E1; expresión E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depende de expr@ posición pos; expresión expr.E1; cst constante; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depende de !cst@ pos << expr.pos; exp << expr.E2; @@ # Truco sucio para ignorar constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Posible cambio de UB aquí") La única otra coincidencia en kernel/sched es rq_clock_thermal() que emplea sched_thermal_decay_shift, y ese exponente ya está limitado a 10, por lo que ese está bien.