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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en curseg->alloc_type Como informó Wenqing Liu en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215657 - Descripción general UBSAN: array-index-out-of-bounds en fs/f2fs/segment.c:3460:2 cuando se monta y opera una imagen dañada - Reproducir probado en kernel 5.17-rc4, 5.17-rc6 1. mkdir test_crash 2. cd test_crash 3. unzip tmp2.zip 4. mkdir mnt 5. ./single_test.sh f2fs 2 - Volcado de kernel [ 46.434454] loop0: se detectó un cambio de capacidad de 0 a 131072 [ 46.529839] F2FS-fs (loop0): montado con la versión de punto de control = 7548c2d9 [ 46.738319] ===================================================================================== [ 46.738412] UBSAN: índice de matriz fuera de los límites en fs/f2fs/segment.c:3460:2 [ 46.738475] el índice 231 está fuera de rango para el tipo 'unsigned int [2]' [ 46.738539] CPU: 2 PID: 939 Comm: umount No contaminado 5.17.0-rc6 #1 [ [46.738547] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 01/04/2014 [ 46.738551] Seguimiento de llamadas: [ 46.738556] [ 46.738563] dump_stack_lvl+0x47/0x5c [ 46.738581] ubsan_epilogue+0x5/0x50 [ 46.738592] __ubsan_handle_out_of_bounds+0x68/0x80 [ 46.738604] f2fs_allocate_data_block+0xdff/0xe60 [f2fs] [ 46.738819] do_write_page+0xef/0x210 [f2fs] [ 46.738934] f2fs_do_write_node_page+0x3f/0x80 [f2fs] [ 46.739038] __write_node_page+0x2b7/0x920 [f2fs] [ 46.739162] f2fs_sync_node_pages+0x943/0xb00 [f2fs] [ 46.739293] f2fs_write_checkpoint+0x7bb/0x1030 [f2fs] [ 46.739405] kill_f2fs_super+0x125/0x150 [f2fs] [ 46.739507] deactivate_locked_super+0x60/0xc0 [ 46.739517] deactivate_super+0x70/0xb0 [ 46.739524] cleanup_mnt+0x11a/0x200 [ 46.739532] __cleanup_mnt+0x16/0x20 [ 46.739538] task_work_run+0x67/0xa0 [ 46.739547] exit_to_user_mode_prepare+0x18c/0x1a0 [ 46.739559] syscall_exit_to_user_mode+0x26/0x40 [ 46.739568] do_syscall_64+0x46/0xb0 [ 46.739584] entry_SYSCALL_64_after_hwframe+0x44/0xae La causa raíz es que olvidamos realizar una verificación de integridad en curseg->alloc_type, lo que da como resultado un acceso fuera de los límites en la matriz sbi->block_count[], corríjalo.