Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm: Evitar la desreferenciación NULL en msm_disp_state_print_regs() Si la asignación en msm_disp_state_dump_regs() falla, entonces `block->state` puede ser NULL. La función msm_disp_state_print_regs() _sí_ tiene código para intentar manejarlo con: if (*reg) dump_addr = *reg; ...pero como "dump_addr" se inicializa a NULL, lo anterior es en realidad un noop. Luego, el código continúa para desreferenciar `dump_addr`. Haga que la función imprima "Registros no almacenados" cuando vea un NULL para resolver esto. Ya que estamos tocando el código, arregle msm_disp_state_print_regs() para que no tome un puntero doble sin sentido y marque correctamente el puntero como `const`. Parche: https://patchwork.freedesktop.org/patch/619657/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda/cs8409: Se corrige una posible desreferencia de NULL. Si snd_hda_gen_add_kctl no puede asignar memoria y devuelve NULL, se producirá una desreferencia de puntero NULL en la siguiente línea. Dado que la función dolphin_fixups es una función hda_fixup que no debería devolver ningún error, se debe agregar una comprobación simple antes de la desreferencia e ignorar el error. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: devmap: proporcionar rxq después de la redirección rxq contiene un puntero al dispositivo desde donde se produjo la redirección. Actualmente, el programa BPF que se ejecutó después de una redirección a través de BPF_MAP_TYPE_DEVMAP* no lo tiene configurado. Esto es particularmente malo ya que se accede a ingress_ifindex, p. ej. SEC("xdp") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC("xdp/devmap") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS; } depende del acceso a rxq, por lo que un puntero NULL se desreferencia: <1>[ 574.475170] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 <1>[ 574.475188] #PF: acceso de lectura del supervisor en modo núcleo <1>[ 574.475194] #PF: error_code(0x0000) - página no presente <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 No contaminado 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Nombre del hardware: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 14/03/2023 <4>[ 574.475231] Cola de trabajo: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Código: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 00000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Rastreo de llamadas: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] proceso_uno_trabajo+0x15d/0x380 <4>[ 574.475566] subproceso_trabajador+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Asegúrese de que los indicadores bpf_redirect internos y de UAPI no se superpongan El bpf_redirect_info se comparte entre las rutas de redireccionamiento de SKB y XDP, y las dos rutas usan los mismos valores de indicador numérico en el campo ri->flags (específicamente, BPF_F_BROADCAST == BPF_F_NEXTHOP). Esto significa que si se usa skb bpf_redirect_neigh() con un argumento params distinto de NULL y, posteriormente, se realiza una redirección de XDP usando la misma estructura bpf_redirect_info, la ruta de XDP se confundirá y terminará fallando, lo que syzbot logró activar. Con el bpf_redirect_info asignado a la pila, la estructura ya no se comparte entre las rutas de SKB y XDP, por lo que el bloqueo ya no ocurre. Sin embargo, el uso de diferentes rutas de código que utilizan valores de indicadores numerados de manera idéntica en el mismo campo de estructura sigue pareciendo un poco confuso, por lo que este parche soluciona el problema juntando las definiciones de indicadores y redefiniendo los tres indicadores en BPF_F_REDIRECT_INTERNAL para que no se superpongan con los indicadores utilizados para XDP. También agrega una comprobación BUILD_BUG_ON() para asegurarse de que la superposición no se vuelva a introducir por error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: be2net: corrige una posible pérdida de memoria en be_xmit(). Be_xmit() devuelve NETDEV_TX_OK sin liberar skb en caso de que be_xmit_enqueue() falle, agregue dev_kfree_skb_any() para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sun3_82586: corrige una posible pérdida de memoria en sun3_82586_send_packet(). sun3_82586_send_packet() devuelve NETDEV_TX_OK sin liberar skb en caso de que skb->len sea demasiado largo, agrega dev_kfree_skb() para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: corregir rpm put() desequilibrado con fence_fini() Actualmente podemos llamar a fence_fini() dos veces si algo sale mal al enviar el GuC CT para la solicitud tlb, ya que señalamos a fence y devolvemos un error, lo que lleva a que el llamador también llame a fini() en la ruta de error en el caso de la versión de pila del flujo, lo que lleva a un rpm put() adicional que más tarde podría hacer que el dispositivo entre en suspensión cuando no debería. Parece que podemos simplemente descartar la llamada a fini() ya que el lado del señalizador de fence ya lo llamará por nosotros. Hay splats misteriosos conocidos con el dispositivo entrando en suspensión incluso con una referencia rpm, y este podría ser un candidato. v2 (Matt B): - Preferimos advertencia si detectamos fini() doble (seleccionado de el commit cfcbc0520d5055825f0647ab922b655688605183)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: No liberar trabajo en TDR Liberar trabajo en TDR no es seguro, ya que TDR puede pasar el subproceso run_job, lo que genera una UAF. Solo es seguro que el programador llame naturalmente al trabajo libre. En lugar de liberar trabajo en TDR, agréguelo a la lista de pendientes. (seleccionado de el commit ea2f6a77d0c40d97f4a4dc93fee4afe15d94926d)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige una posible doble liberación en smb2_set_ea() Advertencia del comprobador estático de Clang (scan-build): fs/smb/client/smb2ops.c:1304:2: Intento de liberar memoria liberada. 1304 | kfree(ea); | ^~~~~~~~~ Hay una doble liberación en tal caso: 'ea se inicializa a NULL' -> 'primera asignación de memoria exitosa para ea' -> 'algo falló, goto sea_exit' -> 'primera liberación de memoria para ea' -> 'goto replay_again' -> 'segundo goto sea_exit antes de asignar memoria para ea' -> 'la segunda liberación de memoria para ea resultó en una doble liberación'. Reinicialice 'ea' a NULL cerca de la etiqueta replay_again, puede solucionar este problema de doble liberación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: No llamar a cleanup en caso de fallo en la reversión del perfil Cuando la reversión del perfil falla en mlx5e_netdev_change_profile, la variable de perfil netdev se deja establecida en NULL. Evite un bloqueo al descargar el controlador al no llamar a profile->cleanup en tal caso. Esto se encontró durante la prueba, con el disparador original de que la creación del hilo wq rescuer se interrumpió (presumiblemente debido a Ctrl+C-ing modprobe), que se convierte a ENOMEM (-12) por mlx5e_priv_init, la reversión del perfil también falla por la misma razón (la señal sigue activa) por lo que el perfil se deja como NULL, lo que lleva a un bloqueo más adelante en _mlx5e_remove. [ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Descargar vfs: modo(OFFLOADS), nvfs(2), necvfs(0), vports(2) activos [ 734.525513] cola de trabajo: Error al crear un kthread de rescate para wq "mlx5e": -EINTR [ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init falló, err=-12 [ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: nuevo Error en la inicialización del perfil, -12 [734.560153] workqueue: Error al crear un kthread de rescate para wq "mlx5e": -EINTR [734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init falló, err=-12 [734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: error al revertir al perfil original, -12 [745.537492] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 [745.538222] #PF: acceso de lectura del supervisor en modo kernel [ 745.551290] Seguimiento de llamadas: [ 745.551590] [ 745.551866] ? __die+0x20/0x60 [ 745.552218] ? page_fault_oops+0x150/0x400 [ 745.555307] ? exc_page_fault+0x79/0x240 [ 745.555729] ? asm_exc_page_fault+0x22/0x30 [ 745.556166] ? mlx5e_remove+0x6b/0xb0 [mlx5_core] [ 745.556698] bus_auxiliar_eliminar+0x18/0x30 [ 745.557134] dispositivo_liberación_controlador_interno+0x1df/0x240 [ 745.557654] bus_eliminar_dispositivo+0xd7/0x140 [ 745.558075] dispositivo_del+0x15b/0x3c0 [ 745.558456] mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core] [ 745.559112] mlx5_anular_registro_dispositivo+0x34/0x50 [mlx5_core] [ 745.559686] mlx5_uninit_one+0x46/0xf0 [mlx5_core] [ 745.560203] remove_one+0x4e/0xd0 [mlx5_core] [ 745.560694] pci_device_remove+0x39/0xa0 [ 745.561112] device_release_driver_internal+0x1df/0x240 [ 745.561631] driver_detach+0x47/0x90 [ 745.562022] bus_remove_driver+0x84/0x100 [ 745.562444] pci_unregister_driver+0x3b/0x90 [ 745.562890] mlx5_cleanup+0xc/0x1b [mlx5_core] [ 745.563415] __x64_sys_delete_module+0x14d/0x2f0 [ 745.563886] ? kmem_cache_free+0x1b0/0x460 [ 745.564313] ? lockdep_hardirqs_on_prepare+0xe2/0x190 [ 745.564825] hacer_syscall_64+0x6d/0x140 [ 745.565223] entrada_SYSCALL_64_after_hwframe+0x4b/0x53 [ 745.565725] RIP: 0033:0x7f1579b1288b

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: PRM: Buscar bloque EFI_MEMORY_RUNTIME para el controlador PRM y el contexto PRMT necesita encontrar el tipo correcto de bloque para traducir la asignación PA-VA para los servicios de tiempo de ejecución EFI. El problema surge porque PRMT encuentra un bloque de tipo EFI_CONVENTIONAL_MEMORY, que no es apropiado para los servicios de tiempo de ejecución como se describe en la Sección 2.2.2 (Servicios de tiempo de ejecución) de la Especificación UEFI [1]. Dado que el controlador PRM es un tipo de servicio de tiempo de ejecución, esto provoca una excepción cuando se llama al controlador PRM. [Error de firmware]: No se puede manejar la solicitud de paginación en el servicio de tiempo de ejecución de EFI ADVERTENCIA: CPU: 22 PID: 4330 en drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Rastreo de llamadas: deje que PRMT encuentre un bloque con EFI_MEMORY_RUNTIME para el controlador PRM y el contexto PRM. Si no se encuentra ningún bloque adecuado, se imprimirá un mensaje de advertencia, pero el procedimiento continúa para administrar el siguiente controlador PRM. Sin embargo, si el controlador PRM se llama realmente sin la asignación adecuada, se produciría un error durante el manejo de errores. Al utilizar los tipos de memoria correctos para los servicios de tiempo de ejecución, asegúrese de que el controlador PRM y el contexto estén correctamente mapeados en el espacio de direcciones virtuales durante el tiempo de ejecución, lo que evita el error de solicitud de paginación. El problema es que el controlador PRM solo puede usar la memoria que el firmware ha reasignado para el tiempo de ejecución, por lo que la región debe tener el atributo EFI_MEMORY_RUNTIME. [ rjw: Tema y ediciones del registro de cambios ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: validar el prefijo de la nueva SA usando la familia de SA cuando sel.family no está configurado Esto expande la validación introducida en el commit 07bf7908950a ("xfrm: validar las longitudes de prefijo de dirección en el selector xfrm"). syzbot creó una SA con usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Debido al selector AF_UNSPEC, verificar_newsa_info no pone límites en prefixlen_{s,d}. Pero luego copy_from_user_state establece x->sel.family en usersa.family (AF_INET). Realice la misma conversión en verificar_newsa_info antes de validar prefixlen_{s,d}, ya que así es como se usará prefixlen más adelante.