Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Trampa desbordamientos de segmentos RDMA Impide que svc_rdma_build_writes() se aleje del final de la matriz de segmentos de un fragmento de escritura. Detectado con KASAN. La prueba que esta corrección reemplaza no es válida y podría haber quedado de un prototipo anterior del trabajo de PCL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: Se corrige el posible use-after-free en nfsd_file_put() nfsd_file_put_noref() puede liberar @nf, por lo que no desreferencia @nf inmediatamente después del regreso de nfsd_file_put_noref().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en la dirección de bloque en f2fs_do_zero_range() Como informó Yanming en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215894 He encontrado un error en el sistema de archivos F2FS en el kernel v5.17. He subido la secuencia de llamada del sistema como case.c, y se puede encontrar una imagen difusa en google net disk El kernel debe habilitar CONFIG_KASAN=y y CONFIG_KASAN_INLINE=y. Puede reproducir el error ejecutando los siguientes comandos: kernel BUG at fs/f2fs/segment.c:2291! Rastreo de llamadas: f2fs_invalidate_blocks+0x193/0x2d0 f2fs_fallocate+0x2593/0x4a70 vfs_fallocate+0x2a5/0xac0 ksys_fallocate+0x35/0x70 __x64_sys_fallocate+0x8e/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae La causa raíz es que, después de que se realizó el análisis difuso de la imagen, la información de mapeo de bloques en el inodo será inconsistente con la tabla SIT, por lo que en f2fs_fallocate(), causará pánico al actualizar SIT con blkaddr no válido. Solucionemos el problema agregando una verificación de cordura en la dirección del bloque antes de actualizar la tabla SIT con ella.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Se solucionó una ejecución de datos en unix_dgram_peer_wake_me(). unix_dgram_poll() llama a unix_dgram_peer_wake_me() sin el bloqueo de `other` y verifica si su cola de recepción está llena. Aquí necesitamos usar unix_recvq_full_lockless() en lugar de unix_recvq_full(), de lo contrario KCSAN informará una ejecución de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí la última para este caso porque el único sitio de llamada en el árbol, net/ipv4/xfrm4_policy.c nunca se compila como modular. (CONFIG_XFRM es booleano)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: lantiq_gswip: Se corrige la pérdida de recuento de referencias en gswip_gphy_fw_list Cada iteración de for_each_available_child_of_node() disminuye el recuento de referencias del nodo anterior. Al salir antes de un bucle for_each_available_child_of_node(), debemos llamar explícitamente a of_node_put() en gphy_fw_np. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de bug_on en ext4_writepages. Tenemos el siguiente problema: Error EXT4-fs (dispositivo loop0): ext4_mb_generate_buddy:1141: grupo 0, mapa de bits de bloque y descriptor de fondo inconsistentes: 25 frente a 31513 cls libres ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/ext4/inode.c:2708! código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep No contaminado 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 00000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 Puede suceder de la siguiente manera: 1. escribir inline_data inodo vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> Si el tamaño de los datos en línea es demasiado pequeño, se asignará un bloque para escribir, luego la asignación tendrá una página sucia ext4_da_convert_inline_data_to_extent -> borrar EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> falla irá a restaurar datos ext4_restore_inline_data ext4_crear_inline_data ext4_write_inline_data ext4_set_inode_state -> establecer inodo EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages si (ext4_has_inline_data(inodo)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) La causa principal de este problema es que destruimos los datos en línea hasta que llamamos a ext4_writepages en el modo de asignación de demora. Pero es posible que ya hayamos convertido de en línea a extendido. Para resolver este problema, primero llamamos a filemap_flush.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: filtrar EXT4_FC_REPLAY del campo s_state del superbloque en disco El bit EXT4_FC_REPLAY en sbi->s_mount_state se usa para indicar que estamos en medio de la reproducción del diario de confirmación rápida. En realidad, esto fue un error, ya que sbi->s_mount_info se inicializa desde es->s_state. Podría decirse que s_mount_state tiene un nombre engañoso, pero el nombre es histórico --- s_mount_state y s_state se remontan a ext2. Lo que se debería haber usado son las funciones en línea ext4_{set,clear,test}_mount_flag(), que establecen los bits EXT4_MF_* en sbi->s_mount_flags. El problema con el uso de EXT4_FC_REPLAY es que un superbloque dañado maliciosamente podría provocar que EXT4_FC_REPLAY se establezca en s_mount_state. Esto evita algunas comprobaciones de cordura y puede desencadenar un error en ext4_es_cache_extent(). Como solución fácil de implementar, filtre el bit EXT4_FC_REPLAY por ahora. Deberíamos dejar de usar EXT4_FC_REPLAY para pasar a algo como EXT4_MF_REPLAY.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí la última para este caso porque el único sitio de llamada en el árbol, drivers/net/phy/phy_device.c nunca se compila como modular. (CONFIG_PHYLIB es booleano)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: altera: Se corrige la pérdida de recuento de referencias en altera_tse_mdio_create Cada iteración de for_each_child_of_node() disminuye el recuento de referencias del nodo anterior. Cuando se interrumpe un bucle for_each_child_of_node(), debemos llamar explícitamente a of_node_put() en el nodo secundario cuando ya no lo necesitamos. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: advertencia de corrección en ext4_handle_inode_extension Tenemos el siguiente problema: Error EXT4-fs (device loop0) en ext4_reserve_inode_write:5741: Sin memoria Error EXT4-fs (device loop0): ext4_setattr:5462: inodo n.º 13: comm syz-executor.0: error mark_inode_dirty Error EXT4-fs (device loop0) en ext4_setattr:5519: Sin memoria Error EXT4-fs (device loop0): ext4_ind_map_blocks:595: inodo n.º 13: comm syz-executor.0: No se pueden asignar bloques para inodos no asignados a extensión con bigalloc ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 4361 en fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Módulos vinculados: CPU: 1 PID: 4361 Comm: syz-executor.0 No contaminado 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 000000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 00000000000000a R13: 000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: do_iter_readv_writev+0x2e5/0x360 do_iter_write+0x112/0x4c0 do_pwritev+0x1e5/0x390 __x64_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 El problema anterior puede ocurrir de la siguiente manera: Suponga que inode.i_size=4096 EXT4_I(inodo)->i_disksize=4096 paso 1: establezca inode->i_isize = 8192 ext4_setattr if (attr->ia_size != inode->i_size) EXT4_I(inodo)->i_disksize = attr->ia_size; rc = ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc sb_getblk devolver -->ENOMEM ... si (!error) ->no se actualizará i_size i_size_write(inodo, attr->ia_size); Ahora: inode.i_size=4096 EXT4_I(inode)->i_disksize=8192 paso 2: Escritura directa de 4096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->devuelve error if (extend) ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize); ->Entonces activa la advertencia. Para resolver el problema anterior, si la marca de inodo sucio falló en ext4_setattr simplemente configure 'EXT4_I(inode)->i_disksize' con el valor anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar ciclos en el directorio h-tree Un sistema de archivos dañado maliciosamente puede contener ciclos en el h-tree almacenados dentro de un directorio. Eso puede hacer que el kernel corrompa fácilmente los nodos del árbol que ya se habían verificado bajo su control mientras realizaba una división de nodos y, en consecuencia, accediera a memoria no asignada. Solucione el problema verificando que los números de bloque recorridos sean únicos.