Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Detectar IP == ksym.end como parte del programa BPF. Ahora que bpf_throw kfunc es la primera instrucción de llamada que no tiene semántica de retorno dentro del verificador, esto también activa el código muerto eliminación de formas sin precedentes. Por un lado, cualquier instrucción que siga a una llamada a bpf_throw nunca se marcará como vista. Además, si una cadena de llamadas termina lanzándose, cualquier instrucción posterior a la instrucción de llamada al subprog que finalmente se lance en las personas que llaman tampoco se marcará como vista. La forma tentadora de solucionar este problema sería emitir instrucciones 'int3' adicionales que superen el jited_len de un programa y garantizar que, durante el tiempo de ejecución, cuando se inicia un programa, podamos descubrir sus límites incluso si la instrucción de llamada a bpf_throw (o a subprogs que siempre tirar) se emite como instrucción final en el programa. Un ejemplo de un programa de este tipo sería este: do_something(): ... r0 = 0 salir foo(): r1 = 0 llamar a bpf_throw r0 = 0 salir de la barra (cond): si r1 != 0 ir a pc+2 llamar a hacer_algo exit call foo r0 = 0 // Nunca visto por el verificador exit // main(ctx): r1 = ... call bar r0 = 0 exit Aquí, si terminamos lanzando, el seguimiento de pila sería el siguiente: bpf_throw foo bar main En bar, la instrucción final emitida será la llamada a foo, como tal, la dirección de retorno será la instrucción posterior (que el JIT emite como int3 en x86). Esto terminará quedando fuera del jited_len del programa, por lo tanto, al desenrollarlo, no podremos descubrir que la dirección del remitente pertenece a ningún programa y terminaremos en pánico debido al desenrollado poco confiable de la pila de programas BPF que nunca esperamos. Para remediar este caso, haga que bpf_prog_ksym_find trate IP == ksym.end como parte del programa BPF, de modo que is_bpf_text_address devuelva verdadero cuando ocurra tal caso, y podamos desenredarlo de manera confiable cuando la instrucción final termine siendo una instrucción de llamada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath12k: corrige una posible escritura fuera de los límites en ath12k_wmi_ext_hal_reg_caps() reg_cap.phy_id se extrae del evento WMI y podría ser un valor inesperado en caso de que ocurran algunos errores. Como resultado, puede ocurrir una escritura fuera de los límites en soc->hal_reg_cap. Solucionarlo validando reg_cap.phy_id antes de usarlo. Esto se encuentra durante la revisión del código. Compilación probada únicamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: Corrección de doble liberación en hci_conn_cleanup syzbot informa un use after free de slab en hci_conn_hash_flush [1]. Después de liberar un objeto usando hci_conn_del_sysfs en la función hci_conn_cleanup, liberar el mismo objeto nuevamente usando las funciones hci_dev_put y hci_conn_put provoca un double free. Aquí hay un flujo simplificado: hci_conn_del_sysfs: hci_dev_put put_device kobject_put kref_put kobject_release kobject_cleanup kfree_const kfree(name) hci_dev_put: ... kfree(name) hci_conn_put: put_device ... kfree(name) Este parche elimina la llamada a las funciones hci_dev_put y hci_conn_put en hci_con función n_cleanup, porque el objeto se libera en la función hci_conn_del_sysfs. Este parche también corrige el recuento en hci_conn_add_sysfs() y hci_conn_del_sysfs() para tener en cuenta las fallas de device_add(). Esto corrige CVE-2023-28464.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpu/hotplug: no desconectar la última CPU no aislada. Si un sistema tiene CPU aisladas mediante el parámetro de línea de comando "isolcpus=", entonces se intenta desconectar la última limpieza La CPU dará como resultado un WARN_ON() al reconstruir los dominios del programador y un pánico posterior debido a una masa de CPU vacía no controlada en particion_sched_domains_locked(). cpuset_hotplug_workfn() build_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset. Effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN)); Por lo tanto, se genera una máscara de CPU vacía que activa la advertencia y luego el bloqueo posterior: ADVERTENCIA: CPU: 4 PID: 80 en kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Seguimiento de llamadas: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+ 0x234/0x880 build_sched_domains_locked+0x37c/0x798 build_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930 No se puede manejar la solicitud de paginación del kernel en la dirección virtual fffe80027ab37080 particion_sched_domains_locked+0x318/0x880 _sched_domains_locked+0x37c/0x798 Aparte del bloqueo resultante, no tiene ningún sentido para desconectar la última CPU de mantenimiento. Evite esto enmascarando las CPU que no son de mantenimiento al seleccionar una CPU de destino para iniciar la operación de desconexión de la CPU a través de la cola de trabajo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btusb: Agregar fecha->evt_skb es un fallo de corrección de verificación NULL debido a punteros nulos [6104.969662] BUG: desreferencia del puntero NULL del kernel, dirección: 00000000000000c8 [6104.969667] #PF: supervisor acceso de lectura en modo kernel [6104.969668] #PF: error_code(0x0000) - página no presente [6104.969670] PGD 0 P4D 0 [6104.969673] Ups: 0000 [#1] SMP NOPTI [6104.969684] RIP: k_hci_wmt_sync+0x144/ 0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 00000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000006 [ 6104.969691] RDX: 00000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 000000000000000 0 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010DS : 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] : 55555554 [6104.969702] Seguimiento de llamadas: [6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [6104.969732] hci_dev_do_close+0x470/ 0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.9 69759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 0007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 00000000000000000 R09: 0000000000000017 [ 6104.969784] 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atl1c:workaround al problema de desbordamiento de DMA RX. Esto se basa en la confirmación del controlador alx 881d0327db37 ("net: alx: solución alternativa al problema de desbordamiento de DMA RX"). Los controladores alx y atl1c tenían un error de desbordamiento de RX, por lo que se creó un asignador personalizado para evitar ciertas direcciones. Luego se creó la solución más simple para el controlador alx, pero no para atl1c debido a la falta de un probador. En lugar de utilizar un asignador personalizado, verifique la dirección skb asignada y use skb_reserve() para alejarse de la dirección problemática 0x...fc0. Probado en AR8131 en Acer 4540.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: no devolver energía no configurada en ieee80211_get_tx_power(). Podemos obtener una advertencia de UBSAN si ieee80211_get_tx_power() devuelve el valor INT_MIN que mac80211 usa internamente para "nivel de energía no configurada". UBSAN: desbordamiento de entero con signo en net/wireless/nl80211.c:3816:5 -2147483648 * 100 no se puede representar en el tipo 'int' CPU: 0 PID: 20433 Comm: insmod Contaminado: G WC OE Call Trace: dump_stack+ 0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [.. .] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] En este caso, simplemente devuelva un error para indicar que no hay datos disponibles.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: se puede corregir el acceso fuera de los límites cuando se lee la información fusionada a través de debugfs. El controlador hns3 define una matriz de cadenas para mostrar la información fusionada, pero si el kernel agrega un nuevo modo o un nuevo estado, puede ocurrir acceso fuera de los límites cuando se lee información fusionada a través de debugfs, este parche soluciona el problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: hisi_sas: establezca el puntero debugfs_dir en NULL después de eliminar debugfs. Si init debugfs falló durante el registro del dispositivo debido a un fallo en la asignación de memoria, se llama a debugfs_remove_recursive(), después de lo cual debugfs_dir no se configura en NULO. Se volverá a llamar a debugfs_remove_recursive() durante la eliminación del dispositivo. Como resultado, se accede a un puntero ilegal. [1665.467244] hisi_sas_v3_hw 0000:b4:02.0: ¡no se pudo iniciar debugfs! ... [1669.836708] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000a0 [1669.872669] pc: down_write+0x24/0x70 [1669.876315] lr: down_write+0x1c/0x70 [1669.879961] sp: ffff000036f53a30 [ 1669.883260] x29: ffff000036f53a30 x28 : ffffa027c31549f8 [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000 [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270 [ 166 9.899122] x23: ffff0000095406b8 x22: ffff0000095406a8 [ 1669.904408] x21: 00000000000000000 x20: ffffa027bf37c310 [ 1669.909695] x19: 000000000a0 x18: ffff8027dcd86f10 [1669.914982] x17: 0000000000000000 x16: 0000000000000000 [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870 [ 1669.925555] x13: 000000000 0000040 x12: 0000000000000228 [1669.930842] x11: 0000000000000020 x10: 0000000000000bb0 [1669.936129] x9: ffff000036f537f0 x8: 73088ca10 [1669.941416] x7: 000000000000001d x6: 00000000ffffffff [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00 [ 1669.951989 ] x3 : ffff000009513e90 x2 : 0000000000000000 [ 1669.95 7276] x1: 00000000000000a0 x0: ffffffff00000001 [1669.962563] Seguimiento de llamadas: [1669.965000] down_write+0x24/0x70 [1669.968301] debugfs_remove_recursive+0x5c/0x1b0 [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main] [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw] [ 1669.984175] pci_device_remove+0x48/0 xd8 [ 1669.988082] device_release_driver_internal+0x1b4/0x250 [ 1669.993282] device_release_driver+0x28/0x38 [ 1669.997534] pci_stop_bus_device +0x84/0xb8 [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40 [ 1670.007244] remove_store+0xfc/0x140 [ 1670.010802] dev_attr_store+0x44/0x60 [ 1670.01444 8] sysfs_kf_write+0x58/0x80 [ 1670.018095] kernfs_fop_write+0xe8/0x1f0 [ 1670.022000] __vfs_write+0x60 /0x190 [ 1670.025472] vfs_write+0xac/0x1c0 [ 1670.028771] ksys_write+0x6c/0xd8 [ 1670.032071] __arm64_sys_write+0x24/0x30 [ 1670.035977] +0x78/0x130 [ 1670.039710] el0_svc_handler+0x38/0x78 [ 1670.043442] el0_svc+0x8/0xc Para solucionar este problema, establezca debugfs_dir en NULL después de debugfs_remove_recursive().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: libfc: corrigió la posible desreferencia del puntero NULL en fc_lport_ptp_setup() fc_lport_ptp_setup() no verificó el valor de retorno de fc_rport_create() que puede devolver NULL y causaría una desreferencia del puntero NULL. Solucione este problema verificando el valor de retorno de fc_rport_create() y el mensaje de error de registro en fc_rport_create() falló.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/jfs: agregue verificación para db_l2nbperpage negativo, l2nbperpage es log2 (número de bloques por página) y el valor mínimo legal debe ser 0, no negativo. En el caso de que l2nbperpage sea negativo, se producirá un error cuando se utilice posteriormente como exponente de desplazamiento. Syzbot informó este error: UBSAN: desplazamiento fuera de los límites en fs/jfs/jfs_dmap.c:799:12 el exponente de desplazamiento -16777216 es negativo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ibmvfc: Eliminar BUG_ON en el caso de un grupo de eventos vacío. En la práctica, el controlador nunca debe enviar más comandos de los asignados al grupo de eventos de una cola. En el improbable caso de que esto suceda, el código afirma un BUG_ON, y en el caso de que el kernel no esté configurado para fallar en caso de pánico, devuelve un puntero de evento basura de la lista de eventos vacía, lo que hace que las cosas vayan en espiral a partir de ahí. Este BUG_ON es un artefacto histórico del controlador ibmvfc que se actualizó por primera vez, y ahora es bien sabido que el uso de BUG_ON es una mala práctica, excepto en el escenario más irrecuperable. No hay nada en este escenario que impida al conductor recuperarse y continuar. Elimine el BUG_ON en cuestión de ibmvfc_get_event() y devuelva un puntero NULL en el caso de un grupo de eventos vacío. Actualice todos los sitios de llamadas a ibmvfc_get_event() para comprobar si hay un puntero NULL y realizar la acción de recuperación o error adecuada.