Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Evitar llamada de cola entre programas adjuntos a diferentes ganchos Los programas bpf se pueden adjuntar a funciones del kernel, y las funciones adjuntas pueden tomar diferentes parámetros o devolver diferentes valores de retorno. Si prog adjunto a una función del kernel llama de cola a prog adjunto a otra función del kernel, se podría omitir la verificación del acceso o del valor de retorno de ctx. Por ejemplo, si prog1 está adjunto a func1 que toma solo 1 parámetro y prog2 está adjunto a func2 que toma dos parámetros. Dado que el verificador asume que el bpf ctx pasado a prog2 se construye en base al prototipo de func2, el verificador permite a prog2 acceder al segundo parámetro del bpf ctx que se le pasa. El problema es que el verificador no impide que prog1 pase su bpf ctx a prog2 mediante llamada de cola. En este caso, el bpf ctx pasado a prog2 se construye a partir de func1 en lugar de func2, es decir, se omite la suposición de verificación de acceso a ctx. Otro ejemplo, si BPF LSM prog1 está conectado al gancho file_alloc_security y BPF LSM prog2 está conectado al gancho bpf_lsm_audit_rule_known. El verificador conoce las reglas de valor de retorno para estos dos ganchos, por ejemplo, es legal que bpf_lsm_audit_rule_known devuelva un número positivo 1 y es ilegal que file_alloc_security devuelva un número positivo. Por lo tanto, el verificador permite que prog2 devuelva un número positivo 1, pero no permite que prog1 devuelva un número positivo. El problema es que el verificador no impide que prog1 llame a prog2 a través de una llamada de cola. En este caso, el valor de retorno 1 de prog2 se utilizará como el valor de retorno para el gancho file_alloc_security de prog1. Es decir, se omite la regla del valor de retorno. Este parche agrega una restricción para la llamada de cola para evitar tales omisiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntb: ntb_hw_switchtec: Se corrige la vulnerabilidad de use after free en switchtec_ntb_remove debido a la condición de ejecución En la función switchtec_ntb_add, puede llamar a la función switchtec_ntb_init_sndev, luego &sndev->check_link_status_work se vincula con check_link_status_work. Se puede llamar a switchtec_ntb_link_notification para iniciar el trabajo. Si eliminamos el módulo que llamará a switchtec_ntb_remove para realizar la limpieza, liberará sndev a través de kfree(sndev), mientras que se utilizará el trabajo mencionado anteriormente. La secuencia de operaciones que puede llevar a un error de UAF es la siguiente: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Arréglelo asegurándose de que el trabajo se cancele antes de continuar con la limpieza en switchtec_ntb_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: comprobar si necesitamos reprogramar durante el vaciado de desbordamiento En términos de uso normal de la aplicación, esta lista siempre estará vacía. Y si una aplicación se desborda un poco, tendrá algunas entradas. Sin embargo, obviamente nada impide que syzbot ejecute un caso de prueba que genere un montón de entradas de desbordamiento, y luego vaciarlas puede llevar bastante tiempo. Verifique la necesidad de reprogramar durante el vaciado y elimine nuestros bloqueos y hágalo si es necesario. No hay ningún estado que mantener aquí, ya que los desbordamientos siempre se podan desde el principio de la lista, por lo tanto, está bien eliminar y volver a adquirir los bloqueos al final del bucle.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs-srv: Evitar la desreferencia de puntero nulo durante el establecimiento de la ruta Para el establecimiento de la ruta RTRS, el cliente RTRS inicia y completa con_num de conexiones. Después de establecer todas sus conexiones, la información se intercambia entre el cliente y el servidor a través del mensaje info_req. Durante este intercambio, es esencial que se hayan establecido todas las conexiones y que el estado de la ruta RTRS srv sea CONECTADO. Por lo tanto, agregue estas comprobaciones de cordura para asegurarnos de detectar y abortar el proceso en escenarios de error para evitar la desreferencia de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Fix increasing MSI-X on VF Aumentar el valor de MSI-X en un VF conduce a operaciones de memoria no válidas. Esto se debe a que no se reasignan algunas matrices. Reproductor: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count El MSI-X predeterminado es 16, por lo que 17 y superior desencadenan este problema. KASAN informa: ERROR: KASAN: slab fuera de los límites en ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Lectura de tamaño 8 en la dirección ffff8888b937d180 por la tarea bash/28433 (...) Seguimiento de llamadas: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [hielo] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [hielo] ice_vsi_cfg+0x7f/0x3b0 [hielo] ice_vf_reconfig_vsi+0x114/0x210 [hielo] ice_sriov_set_msix_vec_count+0x3d0/0x960 [hielo] sriov_vf_msix_count_store+0x21c/0x300 (...) Asignado por la tarea 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [hielo] ice_vsi_cfg+0x7f/0x3b0 [hielo] ice_vsi_setup+0x179/0xa30 [hielo] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) Para solucionarlo, utilice ice_vsi_rebuild() en lugar de ice_vf_reconfig_vsi(). Esto hace que las matrices requeridas se reasignen teniendo en cuenta el nuevo recuento de colas (ice_vsi_realloc_stat_arrays()). Establezca req_txq y req_rxq antes de ice_vsi_rebuild(), de modo que realloc utilice el nuevo recuento de colas establecido. Además, ice_vsi_rebuild() no elimina los filtros VSI (ice_fltr_remove_all()), por lo que ice_vf_init_host_cfg() ya no es necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corregir posible maldad en FREE_STATEID Cuando se envían múltiples FREE_STATEID para el mismo stateid de delegación, puede conducir a un posible error de subdesbordamiento de contador o de use after free. En nfsd4_free_stateid() bajo el bloqueo del cliente encontramos un stateid de delegación, sin embargo, el código elimina el bloqueo antes de llamar a nfs4_put_stid(), que permite que otro FREE_STATE encuentre el stateid nuevamente. El primero procederá a liberar el stateid, lo que conduce a un use after free o a la disminución del contador ya puesto a cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tipd: Libera IRQ solo si se solicitó antes. En el modo de sondeo, si no se solicitó ninguna IRQ, no es necesario liberarla. Llama a devm_free_irq() solo si se configura client->irq. Esto corrige la advertencia causada por la eliminación del módulo tps6598x: ADVERTENCIA: CPU: 2 PID: 333 en kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Rastreo de llamadas: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 hacer_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: bus: se corrige la doble liberación en la API del controlador bus_register() Para bus_register(), cualquier error que ocurra después de kset_register() provocará que @priv se libere dos veces, lo que se soluciona configurando @priv con NULL después de la primera liberación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir UAF en descifrado asincrónico Al realizar un descifrado asincrónico (lectura grande), se produce un bloqueo con un método slab-use-after-free en la API de cifrado. Reproductor: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ===================================================================== [ 194.196844] ERROR: KASAN: slab-use-after-free en gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Lectura de tamaño 8 en la dirección ffff888112bd0448 por la tarea kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 No contaminado 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Cola de trabajo: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Seguimiento de llamadas: [ 194.200191] [ [194.200327] dump_stack_lvl+0x4e/0x70 [194.200558] ? gf128mul_4k_lle+0xc1/0x110 [194.200809] print_report+0x174/0x505 [194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [194.201352] ? srso_return_thunk+0x5/0x5f [194.201604] ? __virt_addr_valid+0xdf/0x1c0 [194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs] Esto se debe a que TFM se está utilizando en paralelo. Solucione esto asignando un nuevo TFM AEAD para el descifrado asincrónico, pero conserve el existente para los casos de LECTURA sincrónica (similar a lo que se hace en smb3_calc_signature()). También elimine las llamadas a aead_request_set_callback() y crypto_wait_req() ya que siempre será una operación sincrónica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: uvc: Corrige la desreferenciación de ERR_PTR en uvc_v4l2.c Corrige la posible desreferenciación de ERR_PTR() en find_format_by_pix() y uvc_v4l2_enum_format(). Corrige los siguientes errores de coincidencia: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: posible desreferenciación de 'fmtdesc' a ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: posible desreferenciación de 'fmtdesc' a ERR_PTR() Además, corrige un problema similar en uvc_v4l2_try_format() para una posible desreferenciación de ERR_PTR().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: No encender el dispositivo después de un error no fatal el commit 004d25060c78 ("igb: Reparar igb_down colgado en eliminación sorpresa") cambió igb_io_error_detected() para ignorar los errores pcie no fatales con el fin de evitar que la tarea se cuelgue que puede suceder cuando se llama a igb_down() varias veces. Esto causó un problema al procesar errores transitorios no fatales. igb_io_resume(), que se llama después de igb_io_error_detected(), asume que el dispositivo es derribado por igb_io_error_detected() si la interfaz está activa. Esto resultó en un pánico con el seguimiento de pila a continuación. [ T3256] igb 0000:09:00.0 haeth0: igb: el enlace NIC haeth0 está inactivo [ T292] pcieport 0000:00:1c.5: AER: Error no corregido (no fatal) recibido: 0000:09:00.0 [ T292] igb 0000:09:00.0: Error de bus PCIe: gravedad=No corregido (no fatal), tipo=Capa de transacción, (ID del solicitante) [ T292] igb 0000:09:00.0: dispositivo [8086:1537] estado/máscara de error=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: Encabezado TLP: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión error_detected [ T292] igb 0000:09:00.0: Se informó un error no fatal y no corregible. [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión mmio_enabled [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión de reanudación [ T292] ------------[ cortar aquí ]------------ [ T292] ¡ERROR del kernel en net/core/dev.c:6539! [ T292] código de operación no válido: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Seguimiento de llamadas: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] ? igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? informe_congelado_detectado+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? deshabilitar_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? Para solucionar este problema, igb_io_resume() verifica si la interfaz está ejecutándose y si el dispositivo no está inactivo, esto significa que igb_io_error_detected() no inactivó el dispositivo y no es necesario activarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Corregir pérdida de macvlan sincronizando el acceso a mac_filter_hash Este parche soluciona un problema de pérdida de macvlan en el controlador i40e causado por el acceso simultáneo a vsi->mac_filter_hash. La pérdida se produce cuando varios subprocesos intentan modificar mac_filter_hash simultáneamente, lo que genera un estado inconsistente y posibles pérdidas de memoria. Para solucionar esto, ahora envolvemos las llamadas a i40e_del_mac_filter() y ponemos a cero vf->default_lan_addr.addr con spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), lo que garantiza operaciones atómicas y evita el acceso simultáneo. Además, agregamos lockdep_assert_held(&vsi->mac_filter_hash_lock) en i40e_add_mac_filter() para ayudar a detectar problemas similares en el futuro. Pasos de reproducción: 1. Genere VFs y configure el puerto VLAN en ellos. 2. Active operaciones MACVLAN simultáneas (por ejemplo, agregar y eliminar filtros MAC o PortVLAN). 3. Observe la posible pérdida de memoria y el estado inconsistente en el hash de filtro MAC. Esta sincronización garantiza la integridad del hash de filtro MAC y evita la pérdida descrita.