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.

In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Possible UB shift here") The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine.