Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> i40e: Solución a la fuga del contador de preemption en el tracepoint de sondeo de napi<br /> <br /> Usar get_cpu() en la asignación del tracepoint causa una fuga obvia del contador de preemption porque nada invoca put_cpu() para deshacerlo:<br /> <br /> &amp;#39;softirq: eh, entró en softirq 3 NET_RX con preempt_count 00000100, salió con 00000101?&amp;#39;<br /> <br /> Esto claramente ha sido sometido a muchas pruebas en los últimos 3+ años...<br /> <br /> Usar smp_processor_id() en su lugar.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> regulator: bq257xx: Corregir fuga de referencia de nodo de dispositivo en bq257xx_reg_dt_parse_gpio()<br /> <br /> En bq257xx_reg_dt_parse_gpio(), si falla al obtener el subhijo, regresa sin llamar a of_node_put(child), causando la fuga de referencia del nodo de dispositivo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mt76: Corregir posible acceso fuera de límites en mt76_connac2_mac_write_txwi_80211()<br /> <br /> Verificar la longitud del frame antes de acceder a los campos mgmt en<br /> mt76_connac2_mac_write_txwi_80211 para evitar un posible acceso fuera de límites.<br /> <br /> [corregir la verificación para que también cubra mgmt-&amp;gt;u.action.u.addba_req.capab, corregir la etiqueta Fixes]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: pm8001: Corrección de uso después de liberación en pm8001_queue_command()<br /> <br /> El commit e29c47fe8946 (&amp;#39;scsi: pm8001: Simplificar pm8001_task_exec()&amp;#39;) refactoriza pm8001_queue_command(), sin embargo, introduce una causa potencial de un escenario de doble liberación cuando cambia la función para que devuelva -ENODEV en caso de estado de phy inactivo/dispositivo desaparecido.<br /> <br /> En esta ruta, pm8001_queue_command() actualiza el estado de la tarea y llama a task_done para indicar a la capa superior que la tarea ha sido gestionada. Sin embargo, esto también libera la tarea SAS subyacente. Entonces se devuelve un -ENODEV al llamador. Cuando libsas sas_ata_qc_issue() recibe este valor de error, asume que la tarea no fue gestionada/enviada a la cola por LLDD y procede a limpiar y liberar la tarea de nuevo, resultando en una doble liberación.<br /> <br /> Dado que pm8001_queue_command() gestiona la tarea SAS en este caso, debería devolver 0 al llamador indicando que la tarea ha sido gestionada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb: cliente: No registrar credenciales en texto plano en cifs_set_cifscreds<br /> <br /> Cuando el registro de depuración está habilitado, cifs_set_cifscreds() registra la carga útil de la clave y expone el nombre de usuario y la contraseña en texto plano. Eliminar el registro de depuración para evitar exponer credenciales.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv6: corrección de desreferencia de puntero NULL en ip6_rt_get_dev_rcu()<br /> <br /> l3mdev_master_dev_rcu() puede devolver NULL cuando el dispositivo esclavo está siendo desasociado de un VRF. Todos los demás llamadores manejan esto, pero perdimos la alternativa a loopback en ip6_rt_pcpu_alloc() -&amp;gt; ip6_rt_get_dev_rcu() con el commit 4832c30d5458 (&amp;#39;net: ipv6: put host and anycast routes on device with address&amp;#39;).<br /> <br /> KASAN: desreferencia de puntero nulo en el rango [0x0000000000000108-0x000000000000010f]<br /> RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)<br /> Traza de Llamadas:<br /> ip6_pol_route (net/ipv6/route.c:2318)<br /> fib6_rule_lookup (net/ipv6/fib6_rules.c:115)<br /> ip6_route_output_flags (net/ipv6/route.c:2607)<br /> vrf_process_v6_outbound (drivers/net/vrf.c:437)<br /> <br /> Me sentí tentado a reelaborar el código de desasociación para borrar la bandera primero e insertar synchronize_rcu() antes de que eliminemos el superior. Pero parece que la alternativa explícita a loopback_dev es un patrón establecido. Y supongo que evitar el synchronize_rcu() también es bueno.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> accel/rocket: corregir el desenrollado en la ruta de error en rocket_probe<br /> <br /> Cuando rocket_core_init() falla (como podría ser el caso con EPROBE_DEFER), necesitamos desenrollar correctamente decrementando el contador que acabamos de incrementar y, si este es el primer núcleo que no pudimos sondear, eliminar también el dispositivo DRM de rocket con rocket_device_fini(). Esto coincide con la lógica en rocket_remove(). No desenrollar correctamente resulta en accesos fuera de límites.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: ems_usb: ems_usb_read_bulk_callback(): comprobar la longitud adecuada de un mensaje<br /> <br /> Al examinar los datos en un urb USB, la actual_length es el tamaño del búfer pasado al controlador, no la transfer_buffer_length que es establecida por el controlador como el tamaño máximo del búfer.<br /> <br /> Al analizar los mensajes en ems_usb_read_bulk_callback(), comprobar correctamente el tamaño tanto al principio del análisis del mensaje para asegurarse de que sea lo suficientemente grande para la estructura esperada, como al final del mensaje para asegurarse de que no desbordemos más allá del final del búfer para el siguiente mensaje.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pinctrl: equilibrium: corregir el rastro de advertencia al cargar<br /> <br /> Las funciones de callback &amp;#39;eqbr_irq_mask()&amp;#39; y &amp;#39;eqbr_irq_ack()&amp;#39; también se llaman en la función de callback &amp;#39;eqbr_irq_mask_ack()&amp;#39;. Esto se hace para evitar la duplicación de código fuente. El problema, es que en la función &amp;#39;eqbr_irq_mask()&amp;#39; también llama a la función gpiolib &amp;#39;gpiochip_disable_irq()&amp;#39;.<br /> <br /> Esto genera el siguiente rastro de advertencia en el log para cada gpio al cargar.<br /> <br /> [ 6.088111] ------------[ cut here ]------------<br /> [ 6.092440] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:3810 gpiochip_disable_irq+0x39/0x50<br /> [ 6.097847] Modules linked in:<br /> [ 6.097847] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.59+ #0<br /> [ 6.097847] Tainted: [W]=WARN<br /> [ 6.097847] RIP: 0010:gpiochip_disable_irq+0x39/0x50<br /> [ 6.097847] Code: 39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 74 06 f0 80 66 09 fb c3 &amp;lt;0f&amp;gt; 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40<br /> [ 6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046<br /> [ 6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX: 0000000000000008<br /> [ 6.097847] RDX: ffff888001be9000 RSI: ffff888001b2dd00 RDI: ffff888001be02a0<br /> [ 6.097847] RBP: ffffc9000000b860 R08: 0000000000000000 R09: 0000000000000000<br /> [ 6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514<br /> [ 6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000<br /> [ 6.097847] FS: 0000000000000000(0000) GS:ffff888041d80000(0000) knlGS:0000000000000000<br /> [ 6.097847] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 6.097847] CR2: 0000000000000000 CR3: 0000000003030000 CR4: 00000000001026b0<br /> [ 6.097847] Call Trace:<br /> [ 6.097847] <br /> [ 6.097847] ? eqbr_irq_mask+0x63/0x70<br /> [ 6.097847] ? no_action+0x10/0x10<br /> [ 6.097847] eqbr_irq_mask_ack+0x11/0x60<br /> <br /> En otro controlador (drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c) la interrupción no se deshabilita aquí.<br /> <br /> Para solucionar esto, no llame a la función &amp;#39;eqbr_irq_mask()&amp;#39; y &amp;#39;eqbr_irq_ack()&amp;#39;. En su lugar, implemente esto directamente sin deshabilitar las interrupciones.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tracing: Añadir comprobación de puntero NULL a trigger_data_free()<br /> <br /> Si trigger_data_alloc() falla y devuelve NULL, event_hist_trigger_parse() salta a la ruta de error out_free. Aunque kfree() maneja de forma segura un puntero NULL, trigger_data_free() no lo hace. Esto causa una desreferencia de puntero NULL en trigger_data_free() al evaluar data-&amp;gt;cmd_ops-&amp;gt;set_filter.<br /> <br /> Corregir el problema añadiendo una comprobación de puntero NULL a trigger_data_free().<br /> <br /> El problema fue encontrado por un agente experimental de revisión de código basado en gemini-3.1-pro mientras revisaba backports en v6.18.y.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nfsd: Corrige la fuga de referencia de cred en nfsd_nl_threads_set_doit().<br /> <br /> syzbot informó una fuga de memoria de la estructura cred. [0]<br /> <br /> nfsd_nl_threads_set_doit() pasa get_current_cred() a nfsd_svc(), pero put_cred() no es llamada después de eso.<br /> <br /> El cred es finalmente pasado a _svc_xprt_create(), que llama a get_cred() con el cred para la estructura svc_xprt.<br /> <br /> La propiedad del contador de referencias por get_current_cred() no es transferida a ningún lugar y simplemente se fuga.<br /> <br /> nfsd_svc() también es llamada desde write_threads(), pero no incrementa file-&amp;gt;f_cred allí.<br /> <br /> nfsd_nl_threads_set_doit() es llamada desde sendmsg() y current-&amp;gt;cred no desaparece.<br /> <br /> Usemos current_cred() en nfsd_nl_threads_set_doit().<br /> <br /> [0]:<br /> ERROR: fuga de memoria<br /> objeto sin referencia 0xffff888108b89480 (tamaño 184):<br /> comm &amp;#39;syz-executor&amp;#39;, pid 5994, jiffies 4294943386<br /> volcado hexadecimal (primeros 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 369454a7):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_noprof+0x412/0x580 mm/slub.c:5270<br /> prepare_creds+0x22/0x600 kernel/cred.c:185<br /> copy_creds+0x44/0x290 kernel/cred.c:286<br /> copy_process+0x7a7/0x2870 kernel/fork.c:2086<br /> kernel_clone+0xac/0x6e0 kernel/fork.c:2651<br /> __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: ucan: Corrección de bucle infinito por mensajes de longitud cero<br /> <br /> Si un dispositivo ucan defectuoso recibe un mensaje con el campo de longitud del mensaje establecido en 0, entonces el controlador entrará en un bucle infinito en ucan_read_bulk_callback(), colgando el sistema. Si la longitud es 0, simplemente omita el mensaje y pase al siguiente.<br /> <br /> Esto ha sido corregido en el controlador kvaser_usb en el pasado en el commit 0c73772cd2b8 (&amp;#39;can: kvaser_usb: leaf: Corrección de posible bucle infinito en los analizadores de comandos&amp;#39;), así que debe haber algunos dispositivos defectuosos por ahí como este en algún lugar.