Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: zonefs: corrección de zonefs_iomap_begin() para lecturas Si se emite una lectura anticipada a un archivo de zona secuencial con un desplazamiento exactamente igual al tamaño de archivo actual, el tipo de iomap se establece en IOMAP_UNWRITTEN, lo que evitará una IO, pero la longitud de iomap se calcula como 0. Esto provoca un WARN_ON() in iomap_iter(): [17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80 [...] [17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80 [...] [17309.754560] Call Trace: [17309.757078] [17309.759240] ? lock_is_held_type+0xd8/0x130 [17309.763531] iomap_readahead+0x1a8/0x870 [17309.767550] ? iomap_read_folio+0x4c0/0x4c0 [17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400 [17309.778848] ? lock_release+0x370/0x750 [17309.784462] ? folio_add_lru+0x217/0x3f0 [17309.790220] ? reacquire_held_locks+0x4e0/0x4e0 [17309.796543] read_pages+0x17d/0xb60 [17309.801854] ? folio_add_lru+0x238/0x3f0 [17309.807573] ? readahead_expand+0x5f0/0x5f0 [17309.813554] ? policy_node+0xb5/0x140 [17309.819018] page_cache_ra_unbounded+0x27d/0x450 [17309.825439] filemap_get_pages+0x500/0x1450 [17309.831444] ? filemap_add_folio+0x140/0x140 [17309.837519] ? lock_is_held_type+0xd8/0x130 [17309.843509] filemap_read+0x28c/0x9f0 [17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs] [17309.856162] ? trace_contention_end+0xd6/0x130 [17309.862416] ? __mutex_lock+0x221/0x1480 [17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs] [17309.875364] ? filemap_get_pages+0x1450/0x1450 [17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620 [17309.888248] ? wait_for_completion_io_timeout+0x20/0x20 [17309.895231] ? lock_is_held_type+0xd8/0x130 [17309.901115] ? lock_is_held_type+0xd8/0x130 [17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs] [17309.913750] new_sync_read+0x2d8/0x520 [17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0 Furthermore, this causes iomap_readahead() se repita eternamente, ya que iomap_readahead_iter() siempre devuelve 0, sin realizar ningún progreso. Solucione esto tratando las lecturas posteriores al tamaño del archivo como accesos a agujeros, configurando el tipo de iomap en IOMAP_HOLE, la dirección de iomap en IOMAP_NULL_ADDR y utilizando el argumento length tal como está para la longitud de iomap. Para simplificar el código con este cambio, zonefs_iomap_begin() se divide en la variante de lectura, zonefs_read_iomap_begin() y zonefs_read_iomap_ops, y la variante de escritura, zonefs_write_iomap_begin() y zonefs_write_iomap_ops.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: agregar bloques GDT reservados comprobar Capturamos un problema de puntero NULL al cambiar el tamaño de una imagen ext4 corrupta que recién borra la característica resize_inode (no ejecuta e2fsck). Podría reproducirse simplemente siguiendo los pasos. El problema se debe a que se borró la característica resize_inode y convertirá el sistema de archivos al modo meta_bg en ext4_resize_fs(), pero es->s_reserved_gdt_blocks no se redujo a cero, por lo que podríamos llamar por error a reserve_backup_gdb() y pasarle un resize_inode no inicializado al agregar nuevos descriptores de grupo. mkfs.ext4 /dev/sda 3G tune2fs -O ^resize_inode /dev/sda #olvidé ejecutar el montaje e2fsck solicitado /dev/sda /mnt resize2fs /dev/sda 8G ======== ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000028 CPU: 19 PID: 3243 Comm: resize2fs No contaminado 5.18.0-rc7-00001-gfde086c5ebfd #748 ... RIP: 0010:ext4_flex_group_add+0xe08/0x2570 ... Seguimiento de llamadas: ext4_resize_fs+0xbec/0x1660 __ext4_ioctl+0x1749/0x24e0 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xa6/0x110 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f2dd739617b ======== La solución es simple, agregue una comprobación en ext4_resize_begin() para asegurarse de que es->s_reserved_gdt_blocks sea cero cuando la función resize_inode esté deshabilitada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de bug_on ext4_mb_use_inode_pa Hulk Robot informó de un BUG_ON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f [...] Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0 [...] ================================================================== El problema anterior puede ocurrir de la siguiente manera: ------------------------------------- do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0); podemos reproducir fácilmente este problema con los siguientes comandos: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1` El tamaño debe ser menor o igual que EXT4_BLOCKS_PER_GROUP. Por lo tanto, puede aparecer "start + size <= ac->ac_o_ex.fe_logical" cuando se trunca el tamaño. Por lo tanto, start debe ser la posición de inicio del grupo donde se encuentra ac_o_ex.fe_logical después de la alineación. Además, cuando el valor de fe_logical o EXT4_BLOCKS_PER_GROUP es muy grande, el valor calculado por start_off es más preciso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cfi: Se solucionó el uso de RCU de __cfi_slowpath_diag con cpuidle El uso de RCU_NONIDLE durante __cfi_slowpath_diag puede generar un estado de RCU no válido en la ruta del código cpuidle: ADVERTENCIA: CPU: 1 PID: 0 en kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138 ... Rastreo de llamadas: rcu_eqs_enter+0xe4/0x138 rcu_idle_enter+0xa8/0x100 cpuidle_enter_state+0x154/0x3a8 cpuidle_enter+0x3c/0x58 do_idle.llvm.6590768638138871020+0x1f4/0x2ec cpu_startup_entry+0x28/0x2c secondary_start_kernel+0x1b8/0x220 __secondary_switched+0x94/0x98 En su lugar, llame a rcu_irq_enter/exit para activar RCU solo cuando sea necesario y deshabilite las interrupciones para toda la verificación del módulo/sombra CFI cuando lo hagamos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm mirror log: redondear el tamaño del mapa de bits de la región a BITS_PER_LONG El código en dm-log redondea bitset_size a 32 bits. Luego usa find_next_zero_bit_le en la región asignada. find_next_zero_bit_le accede al mapa de bits usando punteros largos sin signo. Por lo tanto, en arquitecturas de 64 bits, puede acceder a 4 bytes más allá del tamaño asignado. Corrija este error redondeando bitset_size a BITS_PER_LONG. Este error se encontró ejecutando el conjunto de pruebas lvm2 con kasan.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: lpc32xx_udc: Se corrige la pérdida de recuento de referencias en lpc32xx_udc_probe of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias. of_node_put() verificará el puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: fsl-mc-bus: arregla el use-after-free de KASAN en fsl_mc_bus_remove() En fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io se pasa a fsl_destroy_mc_io(). Sin embargo, mc->root_mc_bus_dev ya está liberado en fsl_mc_device_remove(). Entonces, la referencia a mc->root_mc_bus_dev->mc_io activa el use-after-free de KASAN. Para evitar el use-after-free, mantén la referencia a mc->root_mc_bus_dev->mc_io en una variable local y pásala a fsl_destroy_mc_io(). Este parche necesita ser rediseñado para que se aplique a kernels anteriores a la v5.15.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige un bloqueo durante el desmontaje cuando se está ejecutando la tarea de recuperación del grupo de bloques Cuando iniciamos un desmontaje, en close_ctree(), si tenemos la tarea de recuperación en ejecución y estamos en medio de una reubicación del grupo de bloques de datos, podemos provocar un bloqueo al detener una tarea de recuperación asíncrona, lo que produce un seguimiento como el siguiente: [629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000 [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [629724.501267] Call Trace: [629724.501759] [629724.502174] __schedule+0x3cb/0xed0 [629724.502842] schedule+0x4e/0xb0 [629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs] [629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0 [629724.505442] flush_space+0x423/0x630 [btrfs] [629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50 [629724.507259] ? lock_release+0x220/0x4a0 [629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs] [629724.508940] ? do_raw_spin_unlock+0x4b/0xa0 [629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs] [629724.510922] process_one_work+0x252/0x5a0 [629724.511694] ? process_one_work+0x5a0/0x5a0 [629724.512508] worker_thread+0x52/0x3b0 [629724.513220] ? process_one_work+0x5a0/0x5a0 [629724.514021] kthread+0xf2/0x120 [629724.514627] ? kthread_complete_and_exit+0x20/0x20 [629724.515526] ret_from_fork+0x22/0x30 [629724.516236] [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000 [629724.518269] Call Trace: [629724.518746] [629724.519160] __schedule+0x3cb/0xed0 [629724.519835] schedule+0x4e/0xb0 [629724.520467] schedule_timeout+0xed/0x130 [629724.521221] ? lock_release+0x220/0x4a0 [629724.521946] ? lock_acquired+0x19c/0x420 [629724.522662] ? trace_hardirqs_on+0x1b/0xe0 [629724.523411] __wait_for_common+0xaf/0x1f0 [629724.524189] ? usleep_range_state+0xb0/0xb0 [629724.524997] __flush_work+0x26d/0x530 [629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140 [629724.526580] ? lock_acquire+0x1a0/0x310 [629724.527324] __cancel_work_timer+0x137/0x1c0 [629724.528190] close_ctree+0xfd/0x531 [btrfs] [629724.529000] ? evict_inodes+0x166/0x1c0 [629724.529510] generic_shutdown_super+0x74/0x120 [629724.530103] kill_anon_super+0x14/0x30 [629724.530611] btrfs_kill_super+0x12/0x20 [btrfs] [629724.531246] deactivate_locked_super+0x31/0xa0 [629724.531817] cleanup_mnt+0x147/0x1c0 [629724.532319] task_work_run+0x5c/0xa0 [629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0 [629724.533598] syscall_exit_to_user_mode+0x16/0x40 [629724.534200] do_syscall_64+0x48/0x90 [629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae [629724.535318] RIP: 0033:0x7fa2b90437a7 [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7 [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0 [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200 [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000 [629724.541796] Esto sucede porque: 1) Antes de ingresar a close_ctree() tenemos la tarea de recuperación de grupo de bloques asíncronos ejecutándose y reubicando un grupo de bloques de datos; 2) Hay una tarea de recuperación de espacio de metadatos (o datos) asíncronos ejecutándose; 3) Ingresamos a close_ctree() y estacionamos el kthread más limpio; 4) La tarea de recuperación de espacio asíncrona está en flush_space() y ejecuta todas las entradas retrasadas existentes; 5) Antes de que la tarea de recuperación de espacio asíncrona llame a btrfs_wait_on_delayed_iputs(), la tarea de recuperación de grupo de bloques que está realizando la reubicación del grupo de bloques de datos, crea una entrada ---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ibmvfc: almacenar puntero de vhost durante la asignación de subcrq Actualmente, el puntero hacia atrás de una cola al adaptador de vhost no se establece hasta después del registro de interrupción de subcrq. El valor está disponible cuando se asigna una cola por primera vez y también se puede/debe establecer para colas primarias y asincrónicas, así como para subcrq. Esto corrige un fallo observado durante kexec/kdump en Power 9 con el controlador de interrupción XICS heredado, donde una interrupción de subcrq pendiente del kernel anterior se puede reproducir inmediatamente después del registro de IRQ, lo que resulta en la desreferencia de un puntero hacia atrás basura en ibmvfc_interrupt_scsi(). El kernel intentó leer la página del usuario (58) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000058 Faulting instruction address: 0xc008000003216a08 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc] LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 Call Trace: [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable) [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188 [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310 [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80 [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0 [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130 [c000000014622f60] [0000000020000000] 0x20000000 [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0 [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0 [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170 [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0 [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0 [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230 [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc] [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc] [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc] [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc] [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/mdp4: Se ha corregido la pérdida de recuento de referencias en mdp4_modeset_init_intf. of_graph_get_remote_node() devuelve un puntero de nodo de dispositivo remoto con un recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Se ha añadido el error of_node_put() que falta para evitar la pérdida de recuento de referencias. Patchwork: https://patchwork.freedesktop.org/patch/488473/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: deshabilitar el elevador int del_gendisk El elevador solo se usa para solicitudes del sistema de archivos, que se detienen en del_gendisk. Mueva la desactivación del elevador y la liberación de las etiquetas del programador al final de del_gendisk en lugar de hacer ese trabajo en disk_release y blk_cleanup_queue para evitar un use-after-free en q->tag_set desde disk_release ya que tag_set podría no estar activo en ese punto. Mueva también la llamada blk_qos_exit, ya que solo depende de la salida del elevador y sería la única razón para mantener la congelación de la cola no exactamente barata en disk_release.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: se soluciona un problema de use-after-free en igb_clean_tx_ring Se soluciona el siguiente error de use-after-free en la rutina igb_clean_tx_ring cuando la NIC se ejecuta en modo XDP. El problema se puede desencadenar al redirigir el tráfico a la NIC igb y luego cerrar el dispositivo mientras fluye el tráfico. [ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9 [ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017 [ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0 [ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282 [ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000 [ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0 [ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058 [ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090 [ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000 [ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000 [ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0 [ 73.426565] Call Trace: [ 73.429087] [ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb] [ 73.436002] igb_down+0x1d7/0x220 [igb] [ 73.439974] __igb_close+0x3c/0x120 [igb] [ 73.444118] igb_xdp+0x10c/0x150 [igb] [ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb] [ 73.453362] dev_xdp_install+0xda/0x110 [ 73.457371] dev_xdp_attach+0x1da/0x550 [ 73.461369] do_setlink+0xfd0/0x10f0 [ 73.465166] ? __nla_validate_parse+0x89/0xc70 [ 73.469714] rtnl_setlink+0x11a/0x1e0 [ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0 [ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130 [ 73.482258] netlink_rcv_skb+0x8d/0x110 [ 73.486229] netlink_unicast+0x230/0x340 [ 73.490317] netlink_sendmsg+0x215/0x470 [ 73.494395] __sys_sendto+0x179/0x190 [ 73.498268] ? move_addr_to_user+0x37/0x70 [ 73.502547] ? __sys_getsockname+0x84/0xe0 [ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0 [ 73.511349] ? __sys_setsockopt+0xc8/0x1d0 [ 73.515636] __x64_sys_sendto+0x20/0x30 [ 73.519603] do_syscall_64+0x3b/0x80 [ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 73.528712] RIP: 0033:0x7ff38d41f20c [ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c [ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003 [ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 [ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0 [ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30 [ 73.596545] [ 73.598842] ---[ end trace 0000000000000000 ]---