Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: arkfb: Corrige un error de división por cero en ark_set_pixclock() Dado que el usuario puede controlar los argumentos de ioctl() desde el espacio de usuario, bajo argumentos especiales que pueden resultar en un error de división por cero en: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul); con hdiv=1, pixclock=1 y hmul=2 terminas con (1*1)/2 = (int) 0. y luego en: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock); obtendremos una división por cero. El siguiente registro puede revelarlo: error de división: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [en línea] RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784 Rastreo de llamadas: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Solucione esto marcando el argumento de ark_set_pixclock() primero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: vt8623fb: Verifique el tamaño de la pantalla antes de memset_io() En la función vt8623fb_set_par(), el valor de 'screen_size' se calcula mediante la entrada del usuario. Si el usuario proporciona un valor incorrecto, el valor de 'screen_size' puede ser mayor que 'info->screen_size', lo que puede causar el siguiente error: [ 583.339036] ERROR: no se puede manejar el error de página para la dirección: ffffc90005000000 [ 583.339049] #PF: acceso de escritura del supervisor en modo kernel [ 583.339052] #PF: error_code(0x0002) - página no presente [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0 [ 583.339110] Rastreo de llamadas: [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0 [ 583.339146] fb_set_var+0x604/0xeb0 [ 583.339181] do_fb_ioctl+0x234/0x670 [ 583.339209] fb_ioctl+0xdd/0x130 Solucione este problema comprobando el valor de 'screen_size' antes de memset_io().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/core: No volver a poner en cola la tarea en la CPU excluida de cpus_mask La siguiente advertencia se activó en una máquina grande al comienzo del arranque en un kernel de distribución, pero el mismo problema también debería afectar a la línea principal. ADVERTENCIA: CPU: 439 PID: 10 en ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440 Rastreo de llamadas: rescuer_thread+0x1f6/0x360 kthread+0x156/0x180 ret_from_fork+0x22/0x30 el commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") optimiza ttwu poniendo en cola una tarea que se está desprogramando en la lista de activación, pero no comprueba si la desprogramación de tareas aún puede ejecutarse en esa CPU. En esta advertencia, la tarea problemática es un subproceso de rescate de la cola de trabajo que comprueba si el rescate es para una cola de trabajo por CPU y se ejecuta en la CPU incorrecta. Aunque esto ocurre al principio del arranque y debería ser posible crear trabajadores, el hilo de rescate aún podría usarse si se alcanza el tiempo de espera inicial (MAYDAY_INITIAL_TIMEOUT) o el intervalo (MAYDAY_INTERVAL) y, en una máquina lo suficientemente grande, se usa con frecuencia. El seguimiento confirmó que la tarea debería haberse migrado correctamente utilizando el hilo de parada para gestionar la migración. Sin embargo, una activación paralela de udev, ejecutándose en otra CPU que no comparte caché de CPU, observa p->on_cpu y utiliza task_cpu(p), pone la tarea en cola en la CPU anterior y activa la advertencia. Compruebe que la tarea de activación que se está desprogramando aún pueda ejecutarse en su CPU actual; de no ser así, espere a que se complete la desprogramación y seleccione una CPU permitida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: arkfb: Verifique el tamaño de la pantalla antes de memset_io() En la función arkfb_set_par(), el valor de 'screen_size' se calcula mediante la entrada del usuario. Si el usuario proporciona un valor incorrecto, el valor de 'screen_size' puede ser mayor que 'info->screen_size', lo que puede causar el siguiente error: [ 659.399066] ERROR: no se puede manejar el error de página para la dirección: ffffc90003000000 [ 659.399077] #PF: acceso de escritura del supervisor en modo kernel [ 659.399079] #PF: error_code(0x0002) - página no presente [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0 [ 659.399116] Rastreo de llamadas: [ 659.399122] arkfb_set_par+0x143f/0x24c0 [ 659.399130] fb_set_var+0x604/0xeb0 [ 659.399161] do_fb_ioctl+0x234/0x670 [ 659.399189] fb_ioctl+0xdd/0x130 Solucione este problema comprobando el valor de 'screen_size' antes de memset_io().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Se corrige un fallo debido a un acceso obsoleto a SRB cerca de los tiempos de espera de E/S. Asegúrese de que SRB se devuelva durante la escalada de errores de tiempo de espera de E/S. Si esto no es posible, reinicie la ruta de escalada. Se observó la siguiente pila de fallos: Error: no se puede gestionar la solicitud de paginación del kernel en 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Rastreo de llamadas: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: s3fb: Verifique el tamaño de la pantalla antes de memset_io() En la función s3fb_set_par(), el valor de 'screen_size' se calcula mediante la entrada del usuario. Si el usuario proporciona un valor incorrecto, el valor de 'screen_size' puede ser mayor que 'info->screen_size', lo que puede causar el siguiente error: [ 54.083733] ERROR: no se puede manejar el error de página para la dirección: ffffc90003000000 [ 54.083742] #PF: acceso de escritura del supervisor en modo kernel [ 54.083744] #PF: error_code(0x0002) - página no presente [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Rastreo de llamadas: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Solucione este problema comprobando el valor de 'screen_size' antes de memset_io().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/kprobes: Actualización del indicador de estado de kcb tras el paso único. Se corrigió que kprobes actualizara el indicador de estado de kcb (bloque de control de kprobes) a KPROBE_HIT_SSDONE incluso si kp->post_handler no está configurado. Este error puede causar un pánico del kernel si otro usuario INT3 se ejecuta justo después de kprobes, ya que kprobe_int3_handler() malinterpreta que INT3 es el INT3 de paso único de kprobe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: locking/csd_lock: Cambiar csdlock_debug de early_param a __setup El parámetro csdlock_debug kernel-boot es analizado por la función early_param() csdlock_debug(). Si se establece, csdlock_debug() invoca static_branch_enable() para habilitar la función csd_lock_wait, que desencadena un pánico en arm64 para kernels compilados con CONFIG_SPARSEMEM=y y CONFIG_SPARSEMEM_VMEMMAP=n. Con CONFIG_SPARSEMEM_VMEMMAP=n, se llama a __nr_to_section en static_key_enable() y devuelve NULL, lo que resulta en una desreferencia NULL porque mem_section se inicializa solo más tarde en sparse_init(). Esto también representa un problema para PowerPC, ya que las funciones early_param() se invocan antes que jump_label_init(), lo que también provoca fallos en static_key_enable(). Estos fallos generan la advertencia "Clave estática 'xxx' usada antes de la llamada a jump_label_init()". Por lo tanto, early_param es demasiado pronto para que csd_lock_wait ejecute static_branch_enable(), por lo que se cambia a __setup para solucionarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: reemplazar BTRFS_MAX_EXTENT_SIZE con fs_info->max_extent_size En el sistema de archivos zonificado, la escritura de datos está limitada por max_zone_append_size, y una extensión ordenada grande se divide según el tamaño de un bio. OTOH, el número de extensiones que se escribirán se calcula utilizando BTRFS_MAX_EXTENT_SIZE, y ese número estimado se utiliza para reservar los bytes de metadatos para actualizar y/o crear los elementos de metadatos. La reserva de metadatos se realiza en, por ejemplo, btrfs_buffered_write() y luego se libera de acuerdo con los cambios de estimación. Por lo tanto, si el número de extensiones aumenta masivamente, los metadatos reservados pueden agotarse. El aumento del número de extensiones ocurre fácilmente en el sistema de archivos zonificado si BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. Y causa la siguiente advertencia en un entorno de RAM pequeño con la deshabilitación de la sobreasignación de metadatos (en el siguiente parche). [75721.498492] ------------[ cortar aquí ]------------ [75721.505624] BTRFS: el bloque rsv 1 devolvió -28 [75721.512230] ADVERTENCIA: CPU: 24 PID: 2327559 en fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: cargado Tainted: GW 5.18.0-rc2-BTRFS-ZNS+ #109 [75721.597200] Nombre del hardware: Supermicro Super Server/H12SSL-NT, BIOS 2.0 22/02/2021 [75721.607310] Cola de trabajo: btrfs-endio-write btrfs_work_helper [btrfs] [75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286 [75721.654126] RAX: 00000000000000000 RBX: 0000000000004000 RCX: 0000000000000000 [75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e [75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7 [75721.682493] R10: ffffed13f1a3f8d8 R11: 000000000000001 R12: ffff88980a3c0e28 [75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a [75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000 [75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0 [75721.730499] Rastreo de llamadas: [75721.735166] [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs] [75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs] [75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.769520] ? push_leaf_left+0x420/0x620 [btrfs] [75721.776431] ? memcpy+0x4e/0x60 [75721.781931] split_leaf+0x433/0x12d0 [btrfs] [75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs] [75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs] [75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs] [75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs] [75721.818300] ? lock_downgrade+0x7c0/0x7c0 [75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs] [75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs] [75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs] [75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs] [75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs] [75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs] [75721.869313] ? rcu_read_lock_sched_held+0x16/0x80 [75721.876085] ? lock_release+0x552/0xf80 [75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs] [75721.888886] ? __kasan_check_write+0x14/0x20 [75721.895152] ? do_raw_read_unlock+0x44/0x80 [75721.901323] ? _raw_write_lock_irq+0x60/0x80 [75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs] [75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs] [75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs] [75721.929166] ? _raw_write_unlock+0x23/0x40 [75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs] [75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs] [75721.949906] ? try_to_wake_up+0x30/0x14a0 [75721.955700] ? btrfs_unlink_subvol+0xda---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: garantizar que las páginas se desbloqueen en caso de fallo de cow_file_range() Hay un informe de hung_task en btrfs zonificados como el que se muestra a continuación. https://github.com/naota/linux/issues/59 [726.328648] INFORMACIÓN: la tarea rocksdb:high0:11085 se bloqueó durante más de 241 segundos. [726.329839] No contaminado 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. [726.331603] tarea:rocksdb:high0 estado:D pila: 0 pid:11085 ppid: 11082 indicadores:0x00000000 [726.331608] Seguimiento de llamadas: [726.331611] [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] Mientras depurábamos el problema, encontramos que ejecutar fstests generic/551 en un dispositivo null_blk sin zona de 5 GB en el modo de zona emulada también tenía un problema de bloqueo similar. Además, podemos reproducir el mismo síntoma con un error inyectado en la configuración de cow_file_range(). El bloqueo ocurre cuando cow_file_range() falla en medio de la asignación. cow_file_range() llamado desde do_allocation_zoned() puede dividir la región dada ([inicio, fin]) para la asignación dependiendo de los usos actuales del grupo de bloques. Cuando btrfs puede asignar bytes para una parte de las regiones divididas pero falla para la otra región (por ejemplo, debido a -ENOSPC), devolvemos el error dejando bloqueadas las páginas en las regiones exitosas. Técnicamente, esto solo ocurre cuando @unlock == 0. De lo contrario, desbloqueamos las páginas en una región asignada tras crear una extensión ordenada. Dado que quienes llaman a cow_file_range(unlock=0) no escribirán las páginas, podemos desbloquearlas al salir de cow_file_range() en caso de error. Por lo tanto, podemos asegurar que todas las páginas, excepto @locked_page, se desbloqueen en caso de error. En resumen, cow_file_range ahora se comporta así: - page_started == 1 (valor de retorno): todas las páginas están desbloqueadas. Se inicia la E/S. - unlock == 1: todas las páginas, excepto @locked_page, se desbloquean en cualquier caso. - unlock == 0: en caso de éxito, todas las páginas están bloqueadas para su escritura. - en caso de error, todas las páginas, excepto @locked_page, se desbloquean.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: evitar acceso no válido a memoria mediante node_online(NUMA_NO_NODE) KASAN informa: [ 4.668325][ T0] ERROR: KASAN: acceso a memoria salvaje en dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Lectura de tamaño 8 en la dirección 1fffffff85115558 por el intercambiador de tareas/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 No contaminado 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Nombre del hardware: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 02/03/2016 [ 4.703196][ T0] Rastreo de llamadas: [ 4.706334][ T0] [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) después de convertir el tipo del primer argumento (@nr, número de bit) de arch_test_bit() de `long` a `unsigned long`[0]. Bajo ciertas condiciones (por ejemplo, cuando ACPI NUMA está deshabilitado a través de la línea de comandos), pxm_to_node() puede devolver %NUMA_NO_NODE (-1). Es un número 'mágico' válido de nodo NUMA, pero no un número de bit válido para usar en bitops. node_online() finalmente desciende a test_bit() sin verificar la entrada, asumiendo que está del lado del llamador (lo cual podría ser útil para tareas críticas para el rendimiento). Allí, -1 se convierte en %ULONG_MAX, lo que genera un índice de matriz desproporcionado al calcular la posición del bit en memoria. Por ahora, agregue una verificación explícita de que @node no sea %NUMA_NO_NODE antes de llamar a test_bit(). La lógica real no cambió en absoluto. [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spmi: trace: se corrige el acceso fuera de los límites de la pila en las funciones de seguimiento de SPMI. Las funciones trace_spmi_write_begin() y trace_spmi_read_end() llaman a memcpy() con una longitud de "len + 1". Esto provoca la lectura de un byte adicional más allá del final del búfer especificado. Corrija este acceso fuera de los límites de la pila utilizando una longitud de "len". Aquí hay un registro de KASAN que muestra el problema: ERROR: KASAN: pila fuera de los límites en trace_event_raw_event_spmi_read_end+0x1d0/0x234 Lectura de tamaño 2 en la dirección ffffffc0265b7540 por la tarea thermal@2.0-ser/1314 ... Seguimiento de llamadas: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ... la dirección ffffffc0265b7540 se encuentra en la pila de tareas thermal@2.0-ser/1314 en el desplazamiento 32 en el marco: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] este marco tiene 1 objeto: [32, 33) 'status' Estado de la memoria alrededor de la dirección con errores: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 fffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >fffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00 ====================================================================