Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: aspeed: lpc-snoop: No deshabilite los canales que no están habilitados. Mitigar, por ejemplo, lo siguiente: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] No se puede controlar la desreferencia del puntero NULL del kernel en la dirección virtual 00000004 al escribir [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Error interno: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh No contaminado 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NINGUNO ... [ 120.679543] Rastreo de llamadas: [ 120.679559] misc_deregister de aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove de platform_remove+0x28/0x38 [ 120.700996] platform_remove de device_release_driver_internal+0x188/0x200 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrección del use-after-free en crypt_message al usar criptografía asíncrona. La corrección CVE-2024-50047 eliminó el manejo de criptografía asíncrona de crypt_message(), asumiendo que todas las operaciones de criptografía son síncronas. Sin embargo, cuando se usan aceleradores de criptografía de hardware, esto puede causar fallos de use-after-free: crypt_message() // Asignar el búfer creq que contiene la solicitud creq = smb2_get_aead_req(..., &req); // El cifrado asíncrono devuelve -EINPROGRESS inmediatamente rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Liberar creq mientras la operación asíncrona aún está en progreso kvfree_sensitive(creq, ...); Los módulos de criptografía de hardware a menudo implementan operaciones AEAD asíncronas para mejorar el rendimiento. Cuando crypto_aead_encrypt/decrypt() devuelve -EINPROGRESS, la operación se completa de forma asíncrona. Sin crypto_wait_req(), la función libera inmediatamente el búfer de solicitud, lo que provoca fallos cuando el controlador accede posteriormente a la memoria liberada. Esto genera una condición de use-after-free cuando el controlador de cifrado de hardware accede posteriormente a la estructura de solicitud liberada, lo que provoca fallos del kernel con desreferencias de punteros NULL. El problema se produce porque crypto_alloc_aead() con mask=0 no garantiza la operación síncrona. Incluso sin CRYPTO_ALG_ASYNC en la máscara, se pueden seleccionar implementaciones asíncronas. Solución restaurando el manejo de criptografía asíncrona: - DECLARE_CRYPTO_WAIT(wait) para seguimiento de finalización - aead_request_set_callback() para notificación de finalización asíncrona - crypto_wait_req() para esperar a que se complete la operación Esto garantiza que el búfer de solicitud no se libere hasta que se complete la operación de criptografía, ya sea sincrónica o asincrónica, al tiempo que se conserva la corrección CVE-2024-50047.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: backend: corrección de escritura fuera de límite. El búfer está configurado a 80 caracteres. Si quien llama escribe más caracteres, count se trunca al espacio máximo disponible en "simple_write_to_buffer". Posteriormente, se escribe un terminador de cadena en el búfer en el desplazamiento count sin verificación de los límites. La terminación cero se escribe OUT-OF-BOUND. Para evitarlo, se debe añadir una verificación de que el búfer dado sea menor que el búfer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soundwire: Revertir "soundwire: qcom: Añadir compatibilidad con la API set_channel_map". Esto revierte el commit 7796c97df6b1b2206681a07f3c80f6023a6593d5. Este parche interrumpió la versión Dragonboard 845c (sdm845). Veo: Excepción BRK de kernel inesperada en EL1 Error interno: BRK handler: 00000000f20003e8 [#1] SMP pc : qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom] lr : snd_soc_dai_set_channel_map+0x34/0x78 Call trace: qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom] (P) sdm845_dai_init+0x18c/0x2e0 [snd_soc_sdm845] snd_soc_link_init+0x28/0x6c snd_soc_bind_card+0x5f4/0xb0c snd_soc_register_card+0x148/0x1a4 devm_snd_soc_register_card+0x50/0xb0 sdm845_snd_platform_probe+0x124/0x148 [snd_soc_sdm845] platform_probe+0x6c/0xd0 really_probe+0xc0/0x2a4 __driver_probe_device+0x7c/0x130 driver_probe_device+0x40/0x118 __device_attach_driver+0xc4/0x108 bus_for_each_drv+0x8c/0xf0 __device_attach+0xa4/0x198 device_initial_probe+0x18/0x28 bus_probe_device+0xb8/0xbc deferred_probe_work_func+0xac/0xfc process_one_work+0x244/0x658 worker_thread+0x1b4/0x360 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Kernel panic - not syncing: BRK handler: Fatal exception Dan has also reported following issues with the original patch https://lore.kernel.org/all/33fe8fe7-719a-405a-9ed2-d9f816ce1d57@sabinyo.mountain/ Bug #1: se supone que el elemento cero de ctrl->pconfig[] no se utiliza. Empezamos a contar desde 1. Sin embargo, este código establece ctrl->pconfig[0].ch_mask = 128. Error n.° 2: Hay elementos SLIM_MAX_TX_PORTS (16) en la matriz tx_ch[], pero solo QCOM_SDW_MAX_PORTS + 1 (15) en la matriz ctrl->pconfig[], por lo que corrompe la memoria, como señaló Yongqin Liu. Error 3: Como señaló Jie Gan, borra toda la información de la transmisión junto con la de la recepción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") eliminó accidentalmente la parte crítica del commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), lo que provocaba la reaparición de pánicos de kernel intermitentes en el programa on_switch() de perf, por ejemplo. Restablezca la corrección y añada un comentario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rpl: Se corrige el problema de use-after-free en rpl_do_srh_inline(). Ejecutar lwt_dst_cache_ref_loop.sh en autoprueba con KASAN activa el splat debajo de [0]. rpl_do_srh_inline() recupera ipv6_hdr(skb) y accede a él después de skb_cow_head(), lo cual es ilegal, ya que la cabecera podría liberarse en ese momento. Para solucionarlo, convertimos oldhdr en una estructura local en lugar de un puntero. [0]: [root@fedora net]# ./lwt_dst_cache_ref_loop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543 CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_ ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: net: sierra: comprobar si el endpoint no tiene estado. El controlador comprueba si hay tres endpoints y si hay endpoints de entrada y salida masivos, pero no si el tercer endpoint es una entrada de interrupción. Corrija la omisión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se corrige el error null-ptr-deref en l2cap_sock_resume_cb(). syzbot reportó un error null-ptr-deref en l2cap_sock_resume_cb(). [0] l2cap_sock_resume_cb() presenta un problema similar, corregido con el commit 1bff51ea59a9 ("Bluetooth: Se corrige el error de use-after-free en lock_sock_nested()"). Dado que tanto l2cap_sock_kill() como l2cap_sock_resume_cb() se ejecutan bajo l2cap_sock_resume_cb(), podemos evitar el problema simplemente comprobando si chan->data es NULL. No se accederá al socket eliminado en l2cap_sock_resume_cb(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: hci0 hci_rx_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_conntrack: corrección de fallo debido a la eliminación de una entrada no inicializada Se informó de un fallo en conntrack al intentar desvincular la entrada de conntrack de la lista de cubos hash: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete en ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired en ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get en ffffffffc124efbc [nf_conntrack] [..] La estructura nf_conn está marcada como asignada desde slab, pero parece estar parcialmente inicializada: el puntero hlist ct es basura; parece el valor hash ct (de ahí el fallo). ct->status es igual a IPS_CONFIRMED|IPS_DYING, que es lo esperado ct->timeout es 30000 (=30 s), lo cual es inesperado. Todo lo demás parece una entrada conntrack udp normal. Si ignoramos ct->status y suponemos que es 0, la entrada coincide con las que se acaban de asignar pero que aún no se han insertado en el hash: - los punteros hlist ct están sobrecargados y almacenan/cachean el hash de la tupla sin procesar - ct->timeout coincide con el tiempo relativo esperado para un nuevo flujo udp en lugar del valor absoluto de 'jiffies'. Si no fuera por la presencia de IPS_CONFIRMED, __nf_conntrack_find_get() habría omitido la entrada. La teoría es que alcanzamos la siguiente ejecución: cpu x cpu y cpu z encontró la entrada E encontró la entrada EE está vencida nf_ct_delete() devuelve E a rcu slab init_conntrack E se reinicia, ct->status establecido en 0 respuesta tuplehash hnnode.pprev almacena el valor hash. cpu y encontró E justo antes de que se eliminara en la cpu x. E ahora se reinicia en la cpu z. La cpu y fue interrumpida antes de verificar la expiración y/o el bit de confirmación. ->refcnt establecido en 1 E ahora es propiedad de skb ->timeout establecido en 30000 Si la cpu y se reanudara ahora, observaría que E ha expirado, pero omitiría E debido a que falta el bit CONFIRMED. nf_conntrack_confirm se llama establece: ct->status |= CONFIRMED Esto es incorrecto: E aún no se agregó a la tabla hash. La CPU y se reanuda, observa que E ha expirado pero CONFIRMADO: nf_ct_expired() -> sí (ct->el tiempo de espera es de 30 s) bit confirmado establecido. La CPU y intentará eliminar E de la tabla hash: nf_ct_delete() -> establecer bit MORIR __nf_ct_delete_from_lists Incluso este escenario no garantiza un fallo: la CPU z aún mantiene el/los bloqueo(s) del depósito de la tabla, por lo que y bloquea: esperar a que z mantenga el bloqueo de giro CONFIRMADO está establecido, pero no hay garantía de que ct se agregue al hash: la lógica "chaintoolong" o "clash resolution" omiten el paso de inserción. responder hnnode.pprev aún almacena el valor del hash. desbloquea el bloqueo de giro devolver NF_DROP En caso de que la CPU z inserte la entrada en la tabla hash, la CPU y desvinculará E nuevamente de inmediato, pero no ocurre ningún fallo. Sin la ejecución de la CPU y, la lista de memoria basura no tiene importancia: ct refcnt permanece en 1, skb se liberará y E se destruirá mediante nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy. Para resolver esto, mueva la asignación IPS_CONFIRMED después de la inserción de la tabla, pero antes del desbloqueo. Pablo señala que el almacenamiento de bits de confirmación podría reordenarse para que ocurra antes de la adición de la lista de memoria o de la corrección del tiempo de espera, por lo que se debe cambiar a set_bit y a la barrera de memoria before_atomic para evitarlo. No importa si otras CPU pueden observar una entrada recién insertada justo antes de que se establezca el bit CONFIRMED: este evento no se distingue del caso anterior, "E es la encarnación anterior": la entrada se omitirá. También modifique nf_ct_should_gc() para que primero verifique el bit confirmado. La secuencia de gc es: 1. Verificar si la entrada ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Se corrige la inicialización de datos para instrucciones que escriben en el subdispositivo Se sabe que algunos controladores de instrucciones del subdispositivo Comedi acceden a elementos de datos de instrucción más allá de los primeros elementos `insn->n` en algunos casos. Las funciones `do_insn_ioctl()` y `do_insnlist_ioctl()` asignan al menos `MIN_SAMPLES` (16) elementos de datos para lidiar con esto, pero no inicializan todo eso. Para los códigos de instrucción Comedi que escriben en el subdispositivo, los primeros elementos de datos `insn->n` se copian del espacio de usuario, pero los elementos restantes se dejan sin inicializar. Eso podría ser un problema si el controlador de instrucciones del subdispositivo lee los datos no inicializados. Asegúrese de que los primeros elementos `MIN_SAMPLES` se inicialicen antes de llamar a estos controladores de instrucciones, llenando los elementos no copiados con 0. Para `do_insnlist_ioctl()`, se utilizan los mismos elementos del búfer de datos para manejar una lista de instrucciones, así que asegúrese de que los primeros elementos `MIN_SAMPLES` se inicialicen para cada instrucción que escriba en el subdispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_qfq: Corrección de la condición de ejecución en qfq_aggregate. Una condición de ejecución puede ocurrir cuando se modifica 'agg' en qfq_change_agg (llamado durante qfq_enqueue) mientras otros subprocesos acceden a él simultáneamente. Por ejemplo, qfq_dump_class puede desencadenar una desreferencia a NULL y qfq_delete_class puede causar un use-after-free. Este parche soluciona el problema mediante: 1. El traslado de qfq_destroy_class a la sección crítica. 2. La adición de la protección sch_tree_lock a qfq_dump_class y qfq_dump_class_stats.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Se corrige el uso de datos no inicializados en insn_rw_emulate_bits(). Para las instrucciones `INSN_READ` e `INSN_WRITE` de Comedi en subdispositivos "digitales" (tipos de subdispositivo `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO` y `COMEDI_SUBD_DIO`), es común que el controlador del subdispositivo no tenga las funciones de controlador `insn_read` e `insn_write`, sino una función de controlador `insn_bits` para manejar las instrucciones `INSN_BITS` de Comedi. En ese caso, los punteros del controlador de función `insn_read` y/o `insn_write` del subdispositivo se configuran para apuntar a la función `insn_rw_emulate_bits()` mediante `__comedi_device_postconfig()`. Para `INSN_WRITE`, `insn_rw_emulate_bits()` actualmente asume que el valor `data[0]` proporcionado es una copia válida de la memoria del usuario. Al menos existirá porque `do_insnlist_ioctl()` y `do_insn_ioctl()` en "comedi_fops.c" garantizan la asignación de al menos `MIN_SAMPLES` (16) elementos. Sin embargo, si `insn->n` es 0 (lo cual es permitido para las instrucciones `INSN_READ` e `INSN_WRITE`, entonces `data[0]` puede contener datos no inicializados, y ciertamente contiene datos no válidos, posiblemente de una instrucción diferente en la matriz de instrucciones manejadas por `do_insnlist_ioctl()`. Esto dará como resultado que se escriba un valor incorrecto en el canal de salida digital (o en el canal de entrada/salida digital si se configura como una salida), y puede reflejarse en el estado guardado interno del canal. Arréglelo devolviendo 0 temprano si `insn->n` es 0, antes de llegar al código que accede a `data[0]`. Anteriormente, la función siempre devolvía 1 en caso de éxito, pero se supone que es el número de muestras de datos realmente leídas o escritas hasta `insn->n`, que es 0 en este caso.