Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: Se ha corregido la corrección de null-ptr-deref en mt7925_thermal_init(). Devm_kasprintf() devuelve NULL en caso de error. Actualmente, mt7925_thermal_init() no comprueba este caso, lo que resulta en una desreferencia de puntero NULL. Añada la comprobación de NULL después de devm_kasprintf() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: No registrar los LED para genphy. Si una PHY no tiene controlador, el controlador genphy se prueba/elimina directamente en phy_attach/detach. Si el nodo ofnode de la PHY tiene un subnodo "leds", los LED se (des)registrarán al probar/eliminar el controlador genphy. Esto podría ocurrir si los LED corresponden a un controlador no genérico que no está cargado por cualquier motivo. La eliminación sincrónica del dispositivo PHY en phy_detach genera el siguiente bloqueo: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() Existe un bloqueo correspondiente en el lado de apertura/registro (y este es reportado por lockdep), pero requiere una ejecución mientras que este es determinista. Los PHY genéricos no admiten LED de todos modos, así que no se moleste en registrarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: añadir comprobación NULL en la comprobación de retardo de eswitch. La función ice_lag_is_switchdev_running() se llama desde fuera del código del controlador de eventos LAG. Esto provoca que lag->upper_netdev sea NULL en ocasiones. Para evitar una desreferencia de puntero NULL, es necesario realizar una comprobación antes de desreferenciarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrección duse after free en cifs_oplock_break. Puede producirse una condición de ejecución en cifs_oplock_break() que provoca un use after free de la estructura cinode al desmontar: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [última referencia, iniciar la liberación de sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [más tarde] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF El problema ocurre cuando umount ya ha liberado su referencia al superbloque. Cuando _cifsFileInfo_put() llama a cifs_sb_deactive(), se libera la última referencia, lo que desencadena la limpieza inmediata de todos los inodos bajo RCU. Sin embargo, cifs_oplock_break() continúa accediendo al cinode después de este punto, lo que resulta en un use after free. Para solucionar esto, mantenga una referencia adicional al superbloque durante toda la operación de ruptura del oplock. Esto garantiza que el superbloque y sus inodos sigan siendo válidos hasta que se complete la ruptura del oplock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazo de la cadena de formato %p% en ayudantes similares a bprintf. static const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt)); El programa BPF anterior no se rechaza y genera una advertencia del kernel en tiempo de ejecución: Por favor, elimine el %\x00 no compatible en la cadena de formato. ADVERTENCIA: CPU: 1 PID: 7244 en lib/vsprintf.c:2680 format_decode+0x49c/0x5d0. Esto ocurre porque bpf_bprintf_prepare omite el segundo %, detectado como signo de puntuación, al procesar %p. Este parche lo corrige al no omitir la puntuación. %\x00 se procesa en la siguiente iteración y se rechaza.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: aio_iiro_16: Corregir desplazamiento de bits fuera de los límites Al comprobar un número de IRQ compatible, se utiliza la siguiente prueba: if ((1 << it->options[1]) & 0xdcfc) { Sin embargo, `it->options[i]` es un valor `int` no comprobado del espacio de usuario, por lo que la cantidad de desplazamiento podría ser negativa o estar fuera de los límites. Corrija la prueba exigiendo que `it->options[1]` esté dentro de los límites antes de continuar con la prueba original. Los valores válidos de `it->options[1]` que seleccionan la IRQ estarán en el rango [1,15]. El valor 0 deshabilita explícitamente el uso de interrupciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: pcl812: Corregir desplazamiento de bits fuera de los límites Al comprobar un número de IRQ compatible, se utiliza la siguiente prueba: if ((1 << it->options[1]) & board->irq_bits) { Sin embargo, `it->options[i]` es un valor `int` no comprobado del espacio de usuario, por lo que la cantidad de desplazamiento podría ser negativa o estar fuera de los límites. Corrija la prueba exigiendo que `it->options[1]` esté dentro de los límites antes de continuar con la prueba original. Los valores válidos de `it->options[1]` que seleccionan la IRQ estarán en el rango [1,15]. El valor 0 deshabilita explícitamente el uso de interrupciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: common: st_sensors: Se corrige el uso de estructuras de dispositivo sin inicializar. En las diversas funciones de sondeo, se usa &indio_dev->dev antes de su inicialización. Esto provocaba un pánico del kernel en st_sensors_power_enable() cuando la llamada a devm_regulator_bulk_get_enable() falla y luego se llama a dev_err_probe() con el dispositivo sin inicializar. Esto parece causar un pánico solo con dev_err_probe(); dev_err(), dev_warn() y dev_info() no parecen causarlo, pero también se han corregido. El problema se reporta y rastrea aquí: [1]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: restablecimiento correcto del descriptor de anillo Rx. Cuando el reinicio del dispositivo se activa por cambios en las funciones, como la activación o desactivación de la descarga de la VLAN Rx, se llama a wx->do_reset() para reinicializar los anillos Rx. El anillo de descriptores de hardware puede conservar valores obsoletos de sesiones anteriores. Además, establecer la longitud a 0 en rx_desc[0] provocaría la creación de SKB malformados. Corríjalo para asegurar un borrón y cuenta nueva tras el reinicio del dispositivo. [ 549.186435] [ C16] ------------[ cut here ]------------ [ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814! [ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary) [ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 549.186478] [ C16] RIP: 0010:__pskb_pull_tail+0x3ff/0x510 [ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8 [ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282 [ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2 [ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40 [ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e [ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200 [ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2 [ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000 [ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0 [ 549.186505] [ C16] PKRU: 55555554 [ 549.186507] [ C16] Call Trace: [ 549.186510] [ C16] [ 549.186513] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186517] [ C16] __skb_pad+0xc7/0xf0 [ 549.186523] [ C16] wx_clean_rx_irq+0x355/0x3b0 [libwx] [ 549.186533] [ C16] wx_poll+0x92/0x120 [libwx] [ 549.186540] [ C16] __napi_poll+0x28/0x190 [ 549.186544] [ C16] net_rx_action+0x301/0x3f0 [ 549.186548] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186551] [ C16] ? __raw_spin_lock_irqsave+0x1e/0x50 [ 549.186554] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186557] [ C16] ? wake_up_nohz_cpu+0x35/0x160 [ 549.186559] [ C16] ? srso_alias_return_thunk+0x5/0xfbef5 [ 549.186563] [ C16] handle_softirqs+0xf9/0x2c0 [ 549.186568] [ C16] __irq_exit_rcu+0xc7/0x130 [ 549.186572] [ C16] common_interrupt+0xb8/0xd0 [ 549.186576] [ C16] [ 549.186577] [ C16] [ 549.186579] [ C16] asm_common_interrupt+0x22/0x40 [ 549.186582] [ C16] RIP: 0010:cpuidle_enter_state+0xc2/0x420 [ 549.186585] [ C16] Code: 00 00 e8 11 0e 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 0d ed 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 549.186587] [ C16] RSP: 0018:ffffb391c0277e78 EFLAGS: 00000246 [ 549.186590] [ C16] RAX: ffff8fef5ae40000 RBX: 0000000000000003 RCX: 0000000000000000 [ 549.186591] [ C16] RDX: 0000007fde0faac5 RSI: ffffffff826e53f6 RDI: ffffffff826fa9b3 [ 549.186593] [ C16] RBP: ffff8fe7c3a20800 R08: 0000000000000002 R09: 0000000000000000 [ 549.186595] [ C16] R10: 0000000000000000 R11: 000000000000ffff R12: ffffffff82ed7a40 [ 549.186596] [ C16] R13: 0000007fde0faac5 R14: 0000000000000003 R15: 0000000000000000 [ 549.186601] [ C16] ? cpuidle_enter_state+0xb3/0x420 [ 549.186605] [ C16] cpuidle_en ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: corrección del uso del DMA del búfer Rx. La estructura wx_rx_buffer contenía dos campos de dirección DMA: 'dma' y 'page_dma'. Sin embargo, solo 'page_dma' se inicializó y se utilizó para programar el descriptor Rx. Sin embargo, 'dma' no se inicializó y se utilizó en algunas rutas. Esto podría provocar un comportamiento indefinido, incluyendo errores de DMA o use after free, si se utilizaba 'dma' sin inicializar. Si bien este error aún no se ha producido, conviene corregirlo en el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/ext: Evitar llamadas a update_locked_rq() con rq NULL Evite invocar update_locked_rq() cuando el puntero de la cola de ejecución (rq) sea NULL en las macros SCX_CALL_OP y SCX_CALL_OP_RET. Anteriormente, llamar a update_locked_rq(NULL) con la preempción habilitada podría desencadenar la siguiente advertencia: ERROR: usar __this_cpu_write() en un contexto preemptible [00000000] Esto sucede porque __this_cpu_write() no es seguro para usar en un contexto preemptible. rq es NULL cuando se invoca una operación desde un contexto desbloqueado. En tales casos, no necesitamos almacenar ninguna rq, ya que el valor ya debería ser NULL (desbloqueado). Asegúrese de que update_locked_rq() solo se llame cuando rq no sea NULL, lo que evita llamar a __this_cpu_write() en un contexto preemptible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Arreglar el slab smbd_response para permitir usercopy El manejo de los datos recibidos en el código del cliente smbdirect implica usar copy_to_iter() para copiar datos del tráiler de paquetes de la estructura smbd_reponse a un búfer folioq proporcionado por netfslib que encapsula un trozo de pagecache. Sin embargo, si CONFIG_HARDENED_USERCOPY=y, esto dará como resultado que las comprobaciones realizadas en copy_to_iter() generen un error similar a lo siguiente: CIFS: Intentando montar //172.31.9.1/test CIFS: VFS: Transporte RDMA establecido usercopy: ¡Intento de exposición de memoria del kernel detectado desde el objeto SLUB 'smbd_response_0000000091e24ea1' (desplazamiento 81, tamaño 63)!-----------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopy_abort+0x6c/0x80 ... Call Trace: __check_heap_object+0xe3/0x120 __check_object_size+0x4dc/0x6d0 smbd_recv+0x77f/0xfe0 [cifs] cifs_readv_from_socket+0x276/0x8f0 [cifs] cifs_read_from_socket+0xcd/0x120 [cifs] cifs_demultiplex_thread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 ret_from_fork+0x2b8/0x3b0 ret_from_fork_asm+0x1a/0x30 El problema es que la respuesta smbd_response El campo de paquete de slab no está marcado como permitido para copia de usuario. Se soluciona pasando parámetros a kmem_slab_create() para indicar que se permite copy_to_iter() desde la región de paquete de los objetos slab smbd_response, menos el espacio de encabezado.