CVE-2021-47282

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: bcm2835: corrige el acceso fuera de los límites con más de 4 esclavos. La confirmación 571e31fa60b3 ("spi: bcm2835: valor de registro CS de caché para ->prepare_message()") limitó el número de esclavos a 3 en tiempo de compilación. La limitación fue necesaria por una matriz de tamaño estático prepare_cs[] en los datos privados del controlador que contiene un valor de registro por esclavo. La confirmación buscaba hacer cumplir la limitación en tiempo de ejecución estableciendo num_chipselect del controlador en 3: spi_add_device() rechaza los esclavos con una selección de chip más alta. Sin embargo, la confirmación omitió que num_chipselect solo limita el número de selecciones de chips *nativas*. Si se especifican selecciones de chips GPIO en el árbol de dispositivos para más de 3 esclavos, of_spi_get_gpio_numbers() genera silenciosamente num_chipselect y el resultado son accesos fuera de los límites a la matriz de tamaño estático prepare_cs[]. Como solución curita que se puede volver a transferir a estable, aumente la cantidad de esclavos permitidos a 24 (lo que "debería ser suficiente para cualquiera"), aplique la limitación en esclavo -> configuración y revierta num_chipselect a 3 (que es la cantidad de nativos selecciones de chips admitidas por el controlador). Una próxima confirmación para la próxima permitirá una cantidad arbitraria de esclavos.

In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: Fix out-of-bounds access with more than 4 slaves Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") limited the number of slaves to 3 at compile-time. The limitation was necessitated by a statically-sized array prepare_cs[] in the driver private data which contains a per-slave register value. The commit sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chipselect are rejected by spi_add_device(). However the commit neglected that num_chipselect only limits the number of *native* chipselects. If GPIO chipselects are specified in the device tree for more than 3 slaves, num_chipselect is silently raised by of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to the statically-sized array prepare_cs[]. As a bandaid fix which is backportable to stable, raise the number of allowed slaves to 24 (which "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is the number of native chipselects supported by the controller). An upcoming for-next commit will allow an arbitrary number of slaves.