Vulnerabilidades

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: 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.

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: ext4: se corrige el use-after-free en ext4_rename_dir_prepare Tuvimos el siguiente problema: EXT4-fs (loop0): sistema de archivos montado sin diario. Opciones: ,errores=continuar ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae =================================================================== ERROR: KASAN: use-after-free en ext4_rename_dir_prepare+0x152/0x220 Lectura de tamaño 4 en la dirección ffff88810beee6ae por tarea rep/1895 CPU: 13 PID: 1895 Comm: rep No contaminado 5.10.0+ #241 Seguimiento de llamadas: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 La dirección con errores pertenece a la página: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 000000000000001 000000000000000 00000000ffffffff 000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección con errores: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ====================================================================== Desactivar bloqueo depuración debido a la corrupción del kernel ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 El motivo es que la primera entrada del directorio cuyo 'rec_len' es 34478, obtendrá una entrada principal ilegal. Ahora, no verificamos la entrada del directorio después de leer el bloque del directorio en 'ext4_get_first_dir_block'. Para resolver este problema, verifique la entrada del directorio en 'ext4_get_first_dir_block'. [ Active un ext4_error() en lugar de solo advertir si al directorio le falta una entrada '.' o '..'. También asegúrese de que devolvamos un código de error si el sistema de archivos está dañado. -¡ ...

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: net/mlx5: E-Switch, emparejar solo dispositivos compatibles con OFFLOADS El emparejamiento con devcom solo es posible en dispositivos que admiten LAG. Filtrar en función de las capacidades de retraso. Esto soluciona un problema en el que se llamaba a mlx5_get_next_phys_dev() sin mantener el bloqueo de la interfaz. Este problema se encontró cuando el commit bc4c2f2e0179 ("net/mlx5: Lag, filtrar dispositivos no compatibles") agregó una afirmación que verifica que se mantenga el bloqueo de la interfaz. ADVERTENCIA: CPU: 9 PID: 1706 en drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Módulos vinculados en: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [última descarga: mlx5_core] CPU: 9 PID: 1706 Comm: devlink No contaminado 5.18.0-rc7+ #11 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Código: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff RSP: 0018:ffff88811bf47458 EFLAGS: 00010246 RAX: 000000000000000 RBX: ffff88811b398000 RCX: 000000000000001 RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78 RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437 R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000 R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428 FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core] esw_offloads_enable+0x1153/0x1500 [mlx5_core] ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core] ? wait_for_completion_io_timeout+0x20/0x20 ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core] mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core] ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core] ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core] ? __debugfs_create_file+0x260/0x3e0 mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core] ? mutex_lock_io_nested+0x12c0/0x12c0 ? esw_offloads_disable+0x250/0x250 [mlx5_core] ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470 ? rcu_read_lock_sched_held+0x3f/0x70 devlink_nl_cmd_eswitch_set_doit+0x217/0x620