Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/bridge: anx7625: Se soluciona el problema de desbordamiento al leer EDID La longitud del bloque EDID puede ser mayor a 256 bytes, por lo que deberíamos usar `int` en lugar de `u8` para la variable `edid_pos`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/port: Mantener la referencia del puerto hasta la liberación del decodificador KASAN + DEBUG_KOBJECT_RELEASE informa un posible use-after-free en cxl_decoder_release() donde va a referenciar a su padre, un cxl_port, para liberar su id a port->decoder_ida. ERROR: KASAN: use-after-free en to_cxl_port+0x18/0x90 [cxl_core] Lectura de tamaño 8 en la dirección ffff888119270908 por la tarea kworker/35:2/379 CPU: 35 PID: 379 Comm: kworker/35:2 Contaminado: G OE 5.17.0-rc2+ #198 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Cola de trabajo: eventos kobject_delayed_cleanup Rastreo de llamadas: dump_stack_lvl+0x59/0x73 print_address_description.constprop.0+0x1f/0x150 ? to_cxl_port+0x18/0x90 [cxl_core] kasan_report.cold+0x83/0xdf ? to_cxl_port+0x18/0x90 [cxl_core] to_cxl_port+0x18/0x90 [cxl_core] cxl_decoder_release+0x2a/0x60 [cxl_core] device_release+0x5f/0x100 kobject_cleanup+0x80/0x1c0 El núcleo del dispositivo solo garantiza la duración del elemento primario hasta que se anule el registro de todos los elementos secundarios. Si un elemento secundario necesita un elemento primario para completar su devolución de llamada ->release(), ese elemento secundario debe contener una referencia para extender la duración del elemento primario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la pérdida de memoria en tcp_bpf_sendmsg mientras sk msg está lleno Si tcp_bpf_sendmsg() se está ejecutando mientras sk msg está lleno. Cuando sk_msg_alloc() devuelve el error -ENOMEM, tcp_bpf_sendmsg() va a wait_for_memory. Si sk_msg_alloc() ha asignado memoria parcial, es decir, msg_tx->sg.size es mayor que osize después de sk_msg_alloc(), se produce una pérdida de memoria. Para solucionarlo, utilizamos sk_msg_trim() para liberar la memoria asignada y luego vamos a esperar memoria. Otras rutas de llamada de sk_msg_alloc() tienen un problema similar, como tls_sw_sendmsg(), así que maneje la lógica de sk_msg_trim dentro de sk_msg_alloc(), como sugirió Cong Wang. Este problema puede generar la siguiente información: ADVERTENCIA: CPU: 3 PID: 7950 en net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae ADVERTENCIA: CPU: 3 PID: 2094 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Rastreo de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: pgalloc: reparar pérdida de memoria causada por pgd_free() La página pgd es liberada por la implementación genérica pgd_free() desde el commit f9cb654cb550 ("asm-generic: pgalloc: proporcionar pgd_free() genérico"), sin embargo, hay escenarios en los que el sistema usa más de una página como la tabla pgd, en tales casos la implementación genérica pgd_free() ya no será aplicable. Por ejemplo, cuando PAGE_SIZE_4KB está habilitado y MIPS_VA_BITS_48 no está habilitado en un sistema de 64 bits, la macro "PGD_ORDER" se establecerá como "1", lo que provocará la asignación de dos páginas como la tabla pgd. Bueno, al mismo tiempo, la implementación genérica pgd_free() solo libera una página pgd, lo que provocará la pérdida de memoria. La pérdida de memoria se puede detectar fácilmente ejecutando el comando de shell: "while true; do ls > /dev/null; grep MemFree /proc/meminfo; done"

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mips: cdmm: Se corrige la pérdida de recuento de referencias en mips_cdmm_phys_base La función of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando termine. Agregue el of_node_put() faltante para liberar el recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: atmel: soluciona el problema de recuento de referencias en atmel_nand_controller_init El problema de recuento de referencias ocurre en varias rutas de manejo de errores en un objeto con recuento de referencias "nc->dmac". En estas rutas, la función simplemente devuelve el código de error, olvidando equilibrar el recuento de referencias de "nc->dmac", aumentado anteriormente por dma_request_channel(), lo que puede causar fugas de recuento de referencias. Arréglelo disminuyendo el recuento de referencias de un objeto específico en esas rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: Se ha corregido la gestión de errores en ath10k_setup_msa_resources El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esta función solo llama a of_node_put() en la ruta normal. Y provocará una fuga de refcount en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s: No usar DSISR para fallas SLB Desde el commit 46ddcb3950a2 ("powerpc/mm: Mostrar si un fallo de página incorrecta en los datos es de lectura o escritura") usamos page_fault_is_write(regs->dsisr) en __bad_page_fault() para determinar si el fallo es de lectura o escritura y cambiar el mensaje impreso en consecuencia. Pero las fallas SLB, también conocidas como interrupciones de segmento de datos, no establecen DSISR (registro de estado de interrupción de almacenamiento de datos) en un valor útil. Todas las versiones de ISA desde la v2.03 hasta la v3.1 especifican que la interrupción de segmento de datos establece DSISR "en un valor indefinido". Hasta donde puedo ver, tampoco se menciona que los fallos SLB establezcan DSISR en ningún contenido de BookIV. Esto se manifiesta como accesos que deberían ser de lectura que se informan incorrectamente como escrituras, por ejemplo, al usar el comando "dump" de xmon: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0x5deadbeef0000000 [359526.415611][ C6] Dirección de instrucción con fallas: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) en [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 Si desmontamos la PC, vemos una instrucción de carga: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) También podemos ver en exceptions-64s.S que el bloque data_access_slb no establece IDSISR=1, lo que significa que no carga DSISR en pt_regs. Por lo tanto, el valor que estamos usando para determinar si el error es de lectura/escritura es algún valor obsoleto en pt_regs de un error de página anterior. Reelabore la lógica de impresión para separar el caso de error de SLB y solo imprima lectura/escritura en los casos en los que podamos determinarlo. El resultado se parece a, por ejemplo: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en 0x5deadbeef0000000 [ 721.779697][ C6] Dirección de instrucción con error: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 [ 742.793316][ C6] Instrucción con error dirección: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: Se corrige la pérdida de referencia en tegra_dsi_ganged_probe La referencia tomada por 'of_find_device_by_node()' debe liberarse cuando ya no se necesita. Agregue la llamada put_device() para corregir esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: pm8001: Se ha corregido la interrupción de todas las inicializaciones de tareas. En pm80xx_send_abort_all(), el campo n_elem del ccb utilizado no se inicializa a 0. Esta inicialización faltante a veces provoca que la ruta de finalización de la tarea vea el ccb con un n_elem distinto de cero, lo que da como resultado la ejecución de llamadas dma_unmap_sg() no válidas en pm8001_ccb_task_free(), lo que provoca un bloqueo como el siguiente: [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 00000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Rastreo de llamadas: [ 197.765127] [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx] [ 197.772364] ? do_raw_spin_unlock+0x54/0x220 [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx] [ 197.782406] process_oq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lock_acquire+0x194/0x490 [ 197.790697] ? handle_irq_event+0x10e/0x1b0 [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx] [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0 [ 197.818785] __do_softirq+0x1b5/0x82d [ 197.822485] ? do_raw_spin_unlock+0x54/0x220 [ 197.826799] __irq_exit_rcu+0x17e/0x1e0 [ 197.830678] irq_exit_rcu+0xa/0x20 [ 197.834114] common_interrupt+0x78/0x90 [ 197.840051] [ 197.844236] [ 197.848397] asm_common_interrupt+0x1e/0x40 Evite este problema inicializando siempre el campo n_elem de ccb en 0 en pm8001_send_abort_all(), pm8001_send_read_log() y pm80xx_send_abort_all().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/dp: Se corrige la lectura OOB al manejar el registro Post Cursor2 La matriz link_status no era lo suficientemente grande para leer el registro Post Cursor2 de solicitud de ajuste, por lo que se debe eliminar la función auxiliar común para evitar una lectura OOB, que se encontró con una compilación -Warray-bounds: drivers/gpu/drm/drm_dp_helper.c: En la función 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: el subíndice 10 de la matriz está fuera de los límites de la matriz 'const u8[6]' {también conocido como 'const unsigned char[6]'} [-Werror=array-bounds] 59 | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: nota: al hacer referencia a 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reemplace el único usuario del ayudante con una búsqueda y decodificación de código abierto, similar a drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: se corrige la pérdida de memoria durante la transición de D3hot a D0 Si se establece 'vfio_pci_core_device::needs_pm_restore' (el dispositivo PCI no tiene el bit No_Soft_Reset establecido en su registro de configuración PMCSR), entonces el estado PCI actual se guardará localmente en 'vfio_pci_core_device::pm_save' durante la transición de D0 a D3hot y el mismo se restaurará durante la transición de D3hot a D0. Para guardar el estado PCI localmente, se utiliza pci_store_saved_state() y pci_load_and_free_saved_state() liberará la memoria asignada. Pero para los IOCTL relacionados con el reinicio, el controlador vfio llama a las API relacionadas con el reinicio de PCI que cambiarán internamente el estado de energía de PCI a D0. Por lo tanto, cuando el invitado se reanude, obtendrá el estado actual como D0 y omitirá la llamada a vfio_pci_set_power_state() para cambiar el estado de energía a D0 explícitamente. En este caso, la memoria apuntada por 'pm_save' nunca se liberará. En una secuencia maliciosa, el cambio de estado a D3hot seguido de VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET se puede ejecutar en un bucle y puede causar una situación de OOM. Este parche libera primero la memoria asignada anteriormente antes de sobrescribir 'pm_save' para evitar la pérdida de memoria mencionada.