CVE-2021-47275

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evita solicitudes de lectura de gran tamaño en la ruta del código faltante de la caché. En la ruta del código faltante de la caché del dispositivo almacenado en caché, si una ubicación adecuada del árbol B+ interno coincide con un rango de falta de caché, La función cached_dev_cache_miss() se llamará en cache_lookup_fn() en el siguiente bloque de código, [bloque de código 1] 526 unsigned int sectores = KEY_INODE(k) == s->iop.inode 527? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529: INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Aquí s->d->cache_miss() es el puntero de función de devolución de llamada inicializado como cached_dev_cache_miss(), el último parámetro 'sectors' es una pista importante para calcular el tamaño de la solicitud de lectura al dispositivo de respaldo de los datos de caché faltantes. El cálculo actual en el bloque de código anterior puede generar un valor sobredimensionado de 'sectors', lo que en consecuencia puede desencadenar 2 posibles pánicos del kernel diferentes mediante BUG() o BUG_ON() como se enumera a continuación, 1) BUG_ON() dentro de bch_btree_insert_key(), [bloque de código 2 ] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() dentro de biovec_slab(), [bloque de código 3] 51 predeterminado: 52 BUG(); 53 devuelve NULO; Todos los pánicos anteriores son originales de cached_dev_cache_miss() por el parámetro 'sectors' de gran tamaño. Dentro de cached_dev_cache_miss(), el parámetro 'sectors' se utiliza para calcular el tamaño de los datos leídos desde el dispositivo de respaldo para el caché que falta. Este tamaño se almacena en s->insert_bio_sectors mediante las siguientes líneas de código, [bloque de código 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Luego, la clave real que se inserta en el árbol B+ interno se genera y almacena en s->iop.replace_key mediante las siguientes líneas de código, [bloque de código 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insertar_bio_sectores, 913 s->insertar_bio_sectores); El parámetro 'sectors' de gran tamaño puede provocar pánico 1) mediante BUG_ON() del bloque de código anterior. Y el envío de biografía al dispositivo de respaldo para los datos faltantes se asigna con una sugerencia de s->insert_bio_sectors mediante las siguientes líneas de código, [bloque de código 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); Los 'sectors' de parámetros de gran tamaño pueden provocar pánico 2) mediante BUG() desde el bloque de código anterior. Ahora permítanme explicar cómo se produce el pánico en los "sectors" sobredimensionados. En el bloque de código 5, replace_key se genera mediante la macro KEY(). De la definición de macro KEY(), [bloque de código 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) ( tamaño) << 20) | (inodo), \ 74 .low = (desplazamiento) \ 75 }) Aquí 'tamaño' es un ancho de 16 bits incrustado en el miembro 'alto' de 64 bits de la estructura bkey. Pero en el bloque de código 1, si "KEY_START(k) - bio->bi_iter.bi_sector" es muy probable que sea mayor que (1<<16) - 1, lo que hace que el cálculo del tamaño de la clave b en el bloque de código 5 se desborde. En un informe de error, el valor del parámetro 'sectors' es 131072 (= 1 << 17), los 'sectors' desbordados dan como resultado s->insert_bio_sectors desbordados en el bloque de código 4, luego convierte el campo de tamaño de s->iop.replace_key en sea 0 en el bloque de código 5. Luego, el tamaño 0 s->iop.replace_key se inserta en el árbol B+ interno como clave de verificación de falta de caché (una clave especial para detectar y evitar una ejecución entre la solicitud de escritura normal y la solicitud de lectura faltante de caché) como, [bloque de código 8] 915 ret = ---truncado---