Vulnerabilidad en kernel de Linux (CVE-2022-48902)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no haga WARN_ON() si tenemos configurado PageError. Siempre que realizamos operaciones de búfer de extensión, llamamos a afirmar_eb_page_uptodate() para quejarnos en voz alta si estamos operando en una página no actualizada. Nuestras pruebas nocturnas detectaron esta advertencia a principios de esta semana ADVERTENCIA: CPU: 1 PID: 553508 en fs/btrfs/extent_io.c:6849 afirmar_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: GW 5.17. 0-rc3+ #564 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 01/04/2014 Cola de trabajo: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018 :ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 00000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Seguimiento de llamadas: extend_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree +0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0? terminar_task_switch.isra.0+0xf9/0x3a0 proceso_one_work+0x26d/0x580 ? proceso_one_work+0x580/0x580 trabajador_thread+0x55/0x3b0? proceso_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Esto fue solucionado parcialmente por c2e39305299f01 ("btrfs: borrar la actualización del búfer de extensión cuando no logramos escribirlo"), sin embargo, todo lo que esa solución hizo fue evitar que encontráramos búferes de extensión después de una escritura fallida. Eso no nos impidió seguir usando un búfer que ya habíamos encontrado. En este caso, estamos buscando la raíz de confirmación para almacenar en caché el grupo de bloques, de modo que podamos comenzar a confirmar la transacción, cambiar la raíz de confirmación y luego comenzar a escribir. Después del cambio, podemos buscar un búfer de extensión que aún no se ha escrito y comenzar a procesar ese grupo de bloques. Luego no escribimos ese bloqueo y borramos Actualizar en la página, y luego comenzamos a arrojar estos errores. Normalmente aquí estamos protegidos hasta cierto punto por el candado del árbol. Si leemos un bloque, tenemos la lectura del bloque bloqueada y evitamos que el escritor bloquee el bloque antes de enviarlo para la escritura. Sin embargo, esto no es necesariamente infalible porque la lectura podría ocurrir antes de submit_bio y después de bloquear y desbloquear el búfer de extensión. También en este caso particular tenemos configurado path->skip_locking, por lo que eso no nos salvará aquí. Simplemente obtendremos un bloque que era válido cuando lo leímos, pero dejó de ser válido mientras lo usábamos. Lo que realmente queremos es detectar el caso en el que hemos "leído" un bloque pero no está marcado como Actualizado. Al leer, usamos ClearPageError(), por lo que si estamos !Uptodate y !Error sabremos que no hicimos lo correcto al leer la página. Solucione esto marcando !Uptodate && !Error, de esta manera no nos quejaremos si nuestro búfer se invalida mientras lo estamos usando, y mantendremos el espíritu de la verificación, que es asegurarnos de que tengamos un caché completo. bloquear mientras estamos jugando con él.