Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath11k: liberar un peer para la estación cuando se desconecta del AP para QCA6390/WCN6855. el commit b4a0f54156ac ("ath11k: mover la eliminación del peer después de la detención del vdev de la estación para QCA6390 y WCN6855") es para reparar un fallo del firmware modificando la secuencia de comandos WMI, pero en realidad omite toda la operación de eliminación del peer, por lo que el commit 58595c9874c6 ("ath11k: solucionar el problema del puntero colgante tras un fallo en la eliminación del peer") no tiene efecto y, a continuación, aparece una advertencia de uso tras liberación de KASAN, porque peer->sta no está configurado en NULL y se utiliza más tarde. Se cambia para omitir solo WMI_PEER_DELETE_CMDID para QCA6390/WCN6855. registro de usuario después de liberación: [ 534.888665] ERROR: KASAN: use-after-free en ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888696] Lectura de tamaño 8 en la dirección ffff8881396bb1b8 por la tarea rtcwake/2860 [ 534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: cargado Tainted: GW 5.15.0-wt-ath+ #523 [ 534.888712] Nombre del hardware: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 28/05/2021 [ 534.888716] Seguimiento de llamadas: [ 534.888720] [ 534.888726] dump_stack_lvl+0x57/0x7d [ 534.888736] print_address_description.constprop.0+0x1f/0x170 [ 534.888745] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888771] kasan_report.cold+0x83/0xdf [ 534.888783] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888810] ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888840] ath11k_dp_rx_process_mon_status+0x529/0xa70 [ath11k] [ 534.888874] ? ath11k_dp_rx_mon_status_bufs_replenish+0x3f0/0x3f0 [ath11k] [ 534.888897] ? check_prev_add+0x20f0/0x20f0 [ 534.888922] ? __lock_acquire+0xb72/0x1870 [ 534.888937] ? find_held_lock+0x33/0x110 [ 534.888954] ath11k_dp_rx_process_mon_rings+0x297/0x520 [ath11k] [ 534.888981] ? rcu_read_unlock+0x40/0x40 [ 534.888990] ? ath11k_dp_rx_pdev_alloc+0xd90/0xd90 [ath11k] [ 534.889026] ath11k_dp_service_mon_ring+0x67/0xe0 [ath11k] [ 534.889053] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k] [ 534.889075] call_timer_fn+0x167/0x4a0 [ 534.889084] ? add_timer_on+0x3b0/0x3b0 [ 534.889103] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 534.889117] __run_timers.part.0+0x539/0x8b0 [ 534.889123] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k] [ 534.889157] ? call_timer_fn+0x4a0/0x4a0 [ 534.889164] ? mark_lock_irq+0x1c30/0x1c30 [ 534.889173] ? clockevents_program_event+0xdd/0x280 [ 534.889189] ? mark_held_locks+0xa5/0xe0 [ 534.889203] run_timer_softirq+0x97/0x180 [ 534.889213] __do_softirq+0x276/0x86a [ 534.889230] __irq_exit_rcu+0x11c/0x180 [ 534.889238] irq_exit_rcu+0x5/0x20 [ 534.889244] sysvec_apic_timer_interrupt+0x8e/0xc0 [ 534.889251] [ 534.889254] [ 534.889259] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 534.889265] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 [ 534.889271] Código: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee [ 534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206 [ 534.889284] RAX: 00000000000000006 RBX: 00000000000000200 RCX: ffffffff9f256f10 [ 534.889289] RDX: 00000000000000000 RSI: fffffffa1c6e420 RDI: 00000000000000001 [ 534.889293] RBP: ffff8881095e6200 R08: 00000000000000001 R09: ffffffffa40d2b8f [ 534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68 [ 534.889302] R13: ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000 [ 534.889316] ? mark_lock+0xd0/0x14a0 [ 534.889332] klist_next+0x1d4/0x450 [ 534.889340] ? dpm_wait_for_subordinate+0x2d0/0x2d0 [ 534.889350] device_for_each_child+0xa8/0x140 [ 534.889360] ? device_remove_class_symlinks+0x1b0/0x1b0 [ 534.889370] ? __lock_release+0x4bd/0x9f0 [ 534.889378] ? dpm_suspend+0x26b/0x3f0 [ 534.889390] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: wcd934x: Agregar la falta de of_node_put() en wcd934x_codec_parse_data El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esto es similar a el commit 64b92de9603f ("ASoC: wcd9335: corregir una referencia filtrada agregando la falta de of_node_put")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: mt8195: Se corrige la gestión de errores en mt8195_mt6359_rt1019_rt5682_dev_probe 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 regular. Y provocará una fuga de refcount en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dax: asegúrese de que los inodos se vacíen antes de destruir la caché. Se puede activar un error con el siguiente comando $ modprobe nd_pmem && modprobe -r nd_pmem [ 10.060014] ERROR dax_cache (no contaminado): objetos restantes en dax_cache en __kmem_cache_shutdown() [ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node) [ 10.062433] Seguimiento de llamadas: [ 10.062673] dump_stack_lvl+0x34/0x44 [ 10.062865] slab_err+0x90/0xd0 [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0 [ 10.063848] kmem_cache_destroy+0x4a/0x110 [ 10.064058] __x64_sys_delete_module+0x265/0x300 Esto se debe a que dax_fs_exit() no vacía los inodos antes de destruir la caché. Para solucionar este problema, llame a rcu_barrier() antes de destruir la caché.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dp: rellenar el conector de struct dp_panel DP CTS caso de prueba 4.2.2.6 tiene un edid válido con suma de comprobación incorrecta a propósito y espera que la fuente DP devuelva la suma de comprobación correcta. Durante la lectura del edid de drm, se calcula la suma de comprobación del edid correcta y se almacena en connector::real_edid_checksum. El problema es que struct dp_panel::connector nunca se asigna, en su lugar el conector se almacena en struct msm_dp::connector. Cuando ejecutamos el caso de prueba de prueba de cumplimiento 4.2.2.6 dp_panel_handle_sink_request() no tendrá un edid válido establecido en struct dp_panel::edid, por lo que intentaremos usar el conector real_edid_checksum y nos encontraremos con un error de desreferencia de puntero NULL porque el puntero del conector nunca se asigna. Cambios en V2: -- rellenar el conector del panel en msm_dp_modeset_init() en lugar de en dp_panel_read_sink_caps() Cambios en V3: -- eliminar el texto de confirmación de seguimiento de fallos del núcleo que no es de ayuda -- eliminar el cambio de nombre del parámetro dp_display a dp Cambios en V4: -- añadir más detalles al texto de confirmación Cambios en v10: -- agrupar en una serie Cambios en v11: -- eliminar drm/msm/dp: dp_link_parse_sink_count() retorna inmediatamente si se lee aux. Firmado por: Kuogee Hsieh

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: power: supply: ab8500: Se corrige la pérdida de memoria en ab8500_fg_sysfs_init kobject_init_and_add() toma la referencia incluso cuando falla. Según la documentación de kobject_init_and_add(): Si esta función devuelve un error, se debe llamar a kobject_put() para limpiar correctamente la memoria asociada con el objeto. Corrija la pérdida de memoria llamando a kobject_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921s: corrige una posible pérdida de memoria en mt7921_load_patch. Siempre libera datos de firmware al final de la rutina mt7921_load_patch.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: asix: agregar manejo de errores adecuado para errores de lectura de USB Syzbot una vez más alcanzó un valor uninit en el controlador asix. El problema sigue siendo el mismo: asix_read_cmd() lee menos bytes de los que solicitó el llamador. Dado que todas las solicitudes de lectura se realizan a través de asix_read_cmd(), detectemos el error relacionado con USB allí y agreguemos la notación __must_check para asegurarnos de que todos los llamadores realmente verifiquen el valor de retorno. Entonces, este parche agrega una verificación de cordura dentro de asix_read_cmd(), que simplemente verifica si los bytes leídos no son menores que los solicitados y agrega la gestión de errores faltantes de asix_read_cmd() en todo el código del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igc: evitar advertencia del kernel al cambiar los parámetros del anillo RX Llamar a ethtool cambiando los parámetros del anillo RX de esta manera: $ ethtool -G eth0 rx 1024 en igc activa advertencias del kernel como esta: [ 225.198467] ------------[ cortar aquí ]------------ [ 225.198473] Falta anulación del registro, controlador manejado pero corregido [ 225.198485] ADVERTENCIA: CPU: 7 PID: 959 en net/core/xdp.c:168 xdp_rxq_info_reg+0x79/0xd0 [...] [ 225.198601] Seguimiento de llamada: [ 225.198604] [ 225.198609] igc_setup_rx_resources+0x3f/0xe0 [igc] [ 225.198617] igc_ethtool_set_ringparam+0x30e/0x450 [igc] [ 225.198626] ethnl_set_rings+0x18a/0x250 [ 225.198631] genl_family_rcv_msg_doit+0xca/0x110 [ 225.198637] genl_rcv_msg+0xce/0x1c0 [ 225.198640] ? rings_prepare_data+0x60/0x60 [ 225.198644] ? genl_get_cmd+0xd0/0xd0 [ 225.198647] netlink_rcv_skb+0x4e/0xf0 [ 225.198652] genl_rcv+0x24/0x40 [ 225.198655] netlink_unicast+0x20e/0x330 [ 225.198659] netlink_sendmsg+0x23f/0x480 [ 225.198663] sock_sendmsg+0x5b/0x60 [ 225.198667] __sys_sendto+0xf0/0x160 [ 225.198671] ? handle_mm_fault+0xb2/0x280 [ 225.198676] ? do_user_addr_fault+0x1eb/0x690 [ 225.198680] __x64_sys_sendto+0x20/0x30 [ 225.198683] do_syscall_64+0x38/0x90 [ 225.198687] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 225.198693] RIP: 0033:0x7f7ae38ac3aa igc_ethtool_set_ringparam() copia la estructura igc_ring pero no restablece el miembro xdp_rxq_info antes de llamar a igc_setup_rx_resources(). Esto, a su vez, llama a xdp_rxq_info_reg() con un xdp_rxq_info ya registrado. Asegúrese de anular el registro de la estructura xdp_rxq_info primero en igc_setup_rx_resources.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige un error de btf decl_tag al etiquetar una función syzbot informó un error de btf decl_tag con el siguiente seguimiento de pila: error de protección general, probablemente para una dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000000-0x0000000000000007] CPU: 0 PID: 3592 Comm: syz-executor914 No contaminado 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:btf_type_vlen include/linux/btf.h:231 [en línea] RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910 ... Seguimiento de llamadas: btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198 btf_check_all_types kernel/bpf/btf.c:4239 [en línea] btf_parse_type_sec kernel/bpf/btf.c:4280 [en línea] btf_parse kernel/bpf/btf.c:4513 [en línea] btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047 bpf_btf_load kernel/bpf/syscall.c:4039 [en línea] __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4736 [en línea] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae El error kasan se activa con un BTF ilegal como el siguiente: tipo 0: void tipo 1: int tipo 2: decl_tag a func tipo 3 tipo 3: func a func_proto tipo 8 El número total de tipos es 4 y el tipo 3 es ilegal ya que su tipo func_proto está fuera de rango. Actualmente, el tipo de destino de decl_tag puede ser struct/union, var o func. Tanto struct/union como var implementaron sus propias funciones de devolución de llamada 'resolve' y, por lo tanto, se manejan correctamente en el kernel. Pero el tipo func no tiene la función de devolución de llamada 'resolve'. Cuando btf_decl_tag_resolve() intenta verificar el tipo func, intenta obtener vlen de su tipo func_proto, lo que activó el error kasan anterior. Para solucionar el problema, btf_decl_tag_resolve() debe ejecutar btf_func_check() antes de intentar acceder al tipo func_proto. En la implementación actual, el tipo func se verifica con btf_func_check() en la función de verificación principal btf_check_all_types(). Para solucionar el problema de kasan anterior, implementemos la devolución de llamada 'resolve' para el tipo func de manera adecuada. La devolución de llamada 'resolve' también se llamará en btf_check_all_types() para los tipos func.