Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Uso de asignación dinámica para la matriz de ocupación de CU en 'kfd_get_cu_occupancy()' La función `kfd_get_cu_occupancy` declaró anteriormente una matriz `cu_occupancy` grande como una variable local, lo que podría provocar desbordamientos de pila debido al uso excesivo de la pila. Esta confirmación reemplaza la asignación de matriz estática con asignación de memoria dinámica utilizando `kcalloc`, lo que reduce el tamaño de la pila. Este cambio evita el riesgo de desbordamientos de pila en el espacio del kernel, en escenarios donde `AMDGPU_MAX_QUEUES` es grande. La memoria asignada se libera utilizando `kfree` antes de que la función regrese para evitar fugas de memoria. Corrige lo siguiente con gcc W=1: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: En la función 'kfd_get_cu_occupancy': drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:322:1: advertencia: el tamaño del marco de 1056 bytes es mayor que 1024 bytes [-Wframe-larger-than=] 322 | } | ^

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: núcleo: se ha corregido una posible desreferenciación NULL causada por kunit_kzalloc() kunit_kzalloc() puede devolver un puntero NULL, desreferenciarlo sin la comprobación NULL puede provocar una desreferencia NULL. Se han añadido comprobaciones NULL para todos los kunit_kzalloc() en sound_kunit.c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: se corrige el bloqueo recursivo cuando el programa de veredicto devuelve SK_PASS Cuando el programa stream_verdict devuelve SK_PASS, coloca el skb recibido en su propia cola de recepción, pero finalmente se produce un bloqueo recursivo que provoca un bloqueo del sistema operativo. Este problema ha estado presente desde la versión v6.9. ''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # ahora stream_verdict devuelve SK_PASS sin asignación de sock de pares __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= bloqueo muerto ''' Este tema se ha discutido antes, pero no se ha solucionado. Discusión anterior: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en el nodo blkaddr en truncate_node() syzbot informa un error de f2fs como se muestra a continuación: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Seguimiento de llamadas: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [en línea] open_last_lookups fs/namei.c:3694 [en línea] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [en línea] __do_sys_openat fs/open.c:1446 [en línea] __se_sys_openat fs/open.c:1441 [en línea] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 La causa raíz es: en una imagen con errores, blkaddr en la entrada nat puede estar dañado, luego causará un pánico del sistema al usarlo en f2fs_invalidate_blocks(), para evitar esto, agreguemos una verificación de cordura en nat blkaddr en truncar_nodo().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device Si bien en cuanto al diseño la idea de convertir el controlador para usar la jerarquía de los chips IRQ es correcta, la implementación tiene fallas (heredadas). Esto se reveló cuando platform_get_irq() había iniciado WARN() en IRQ 0, que se supone que es un número IRQ de Linux (también conocido como vIRQ). Reelabore el controlador para respetar el dominio IRQ al crear cada dispositivo MFD por separado, ya que el dominio no es el mismo para todos ellos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: brd: aplazar la creación automática de discos hasta que la inicialización del módulo tenga éxito. Mi colega Wupeng encontró los siguientes problemas durante la inyección de fallas: ERROR: no se puede gestionar la falla de página para la dirección: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe No contaminado 6.12.0-rc3+ #17 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Seguimiento de llamadas: blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() está llamando a loop_add() después de que __register_blkdev() tenga éxito e ignora el error de disk_add() de loop_add(), ya que el error de loop_add() no es fatal y los discos creados correctamente ya están visibles para bdev_open().brd_init() actualmente está llamando a brd_alloc() antes de que __register_blkdev() tenga éxito y está liberando discos creados exitosamente cuando brd_init() devuelve un error. Esto puede causar UAF para los últimos dos casos: caso 1: T1: modprobe brd brd_init brd_alloc(0) // éxito add_disk disk_scan_partitions bdev_file_open_by_dev // asignar archivo fput // no se liberará hasta que regrese al espacio de usuario brd_alloc(1) // falló debido a un error de asignación de memoria inject // error la ruta para modprobe liberará el segmento de código // de regreso al espacio de usuario __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops está liberado ahora, ¡UAF! caso 2: T1: T2: modprobe brd brd_init brd_alloc(0) // éxito open(/dev/ram0) brd_alloc(1) // error // ruta de error para modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Solucione este problema siguiendo lo que hace loop_init(). Además, vuelva a introducir brd_devices_mutex para ayudar a serializar las modificaciones a brd_list.

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: epf-mhi: Evitar la desreferenciación NULL si DT carece de 'mmio' Si platform_get_resource_byname() falla y devuelve NULL porque DT carece de una propiedad 'mmio' para el endpoint MHI, la desreferenciación de res->start provocará un acceso al puntero NULL. Agregue una verificación para evitarlo. [kwilczynski: actualización del mensaje de error según los comentarios de la revisión] [bhelgaas: registro de confirmaciones]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: pcrypt - Llamar a la capa de cifrado directamente cuando padata_do_parallel() devuelve -EBUSY Desde el commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), las operaciones de cifrado y descifrado de pcrypt devuelven -EAGAIN cuando la CPU se conecta o desconecta. En alg_test(), se genera una ADVERTENCIA cuando pcrypt_aead_decrypt() o pcrypt_aead_encrypt() devuelve -EAGAIN, el pánico innecesario ocurrirá cuando panic_on_warn se establezca en 1. Solucione este problema llamando a la capa de cifrado directamente sin paralelización en ese caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: musb: Reparar bloqueo de hardware en la primera solicitud de endpoint Rx Existe la posibilidad de que la devolución de llamada de una solicitud pueda invocarse desde usb_ep_queue() (rastreo de llamada a continuación, complementado con llamadas faltantes): req->complete desde usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request desde musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback desde rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate desde musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart desde Según la cadena de documentación de usb_ep_queue(), esto no debería suceder: "Tenga en cuenta que la devolución de llamada ->complete() de @req nunca debe llamarse desde usb_ep_queue() ya que eso puede crear situaciones de bloqueo". De hecho, un bloqueo de hardware podría ocurrir en la siguiente secuencia: 1. El gadget se inicializa usando musb_gadget_enable(). 2. Mientras tanto, llega un paquete y se activa el indicador RXPKTRDY, lo que genera una interrupción. 3. Si las IRQ están habilitadas, se gestiona la interrupción, pero musb_g_rx() encuentra una cola vacía (next_request() devuelve NULL). El indicador de interrupción ya ha sido borrado por el controlador de la capa de pegamento, pero el indicador RXPKTRDY permanece activado. 4. La primera solicitud se pone en cola usando usb_ep_queue(), lo que lleva a la llamada de req->complete(), como se muestra en el seguimiento de la llamada anterior. 5. Si la devolución de llamada habilita las IRQ y hay otro paquete en espera, se repite el paso (3). La cola de solicitudes está vacía porque usb_g_giveback() elimina la solicitud antes de invocar la devolución de llamada. 6. El endpoint permanece bloqueado, ya que se ha gestionado la interrupción provocada por la configuración del hardware del indicador RXPKTRDY, pero el indicador en sí permanece configurado. Para que se produzca este escenario, solo es necesario que las IRQ se habiliten en algún momento durante la devolución de llamada completa. Esto sucede con el dispositivo USB Ethernet, cuya devolución de llamada rx_complete() llama a netif_rx(). Si se llama en el contexto de la tarea, netif_rx() deshabilita las mitades inferiores (BH). Cuando se vuelven a habilitar las BH, también se habilitan las IRQ para permitir que se procesen las IRQ suaves. El dispositivo en sí se inicializa en la carga del módulo (o en el arranque si está integrado), pero la primera solicitud se pone en cola cuando se activa la interfaz de red, lo que activa rx_complete() en el contexto de la tarea a través de ioctl(). Si llega un paquete mientras la interfaz está inactiva, puede impedir que la interfaz reciba más paquetes del host USB. La situación es bastante complicada con muchas partes involucradas. Este problema en particular se puede resolver de varias maneras posibles: 1. Asegúrese de que las devoluciones de llamadas nunca habiliten las IRQ. Esto sería difícil de hacer cumplir, ya que descubrir cómo interactúa netif_rx() con las interrupciones ya era bastante desafiante y u_ether no es el único controlador de función. También podrían estar ocultos "errores" similares en otros controladores. 2. Desactive las interrupciones MUSB en musb_g_giveback() antes de llamar a la devolución de llamada y vuelva a habilitarlas después (llamando a musb_{dis,en}able_interrupts(), por ejemplo). Esto garantizaría que las interrupciones MUSB no se gestionen durante la devolución de llamada, incluso si las IRQ están habilitadas. De hecho, permitiría que las IRQ se habiliten al liberar el bloqueo. Sin embargo, esto parece un truco poco elegante. 3. Modifique el controlador de interrupciones para borrar el indicador RXPKTRDY si la cola de solicitudes está vacía. Si bien este enfoque también parece un truco, desperdicia tiempo de CPU al intentar gestionar paquetes entrantes cuando el software no está listo para procesarlos. ---trunqué---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sunrpc: borrar XPRT_SOCK_UPD_TIMEOUT al reiniciar el transporte Dado que transport->sock se ha establecido en NULL durante el reinicio del transporte, también es necesario borrar XPRT_SOCK_UPD_TIMEOUT. De lo contrario, xs_tcp_set_socket_timeouts() puede activarse en xs_tcp_send_request() para desreferenciar el transport->sock que se ha establecido en NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: buzón: mtk-cmdq: corrige el uso incorrecto de sizeof en cmdq_get_clocks(). Debe ser el tamaño de la estructura clk_bulk_data, no el puntero de datos pasado a devm_kcalloc().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: comprobar que num_codecs no es cero para evitar el pánico durante el sondeo Después de el commit 13f58267cda3 ("ASoC: soc.h: no crear un componente ficticio mediante COMP_DUMMY()"), COMP_DUMMY() se convirtió en una matriz con longitud cero y solo se rellena con la estructura ficticia después de que se registra la tarjeta. Dado que el sondeo del controlador de la tarjeta de sonido ocurre antes del registro de la tarjeta, acceder a cualquiera de los miembros de un componente ficticio durante el sondeo dará como resultado un comportamiento indefinido. Esto se puede observar en los controladores de sonido de las máquinas mt8188 y mt8195. Al omitir un subnodo de enlace dai en el nodo de la tarjeta de sonido en Devicetree, se utiliza el códec ficticio no inicializado predeterminado y, cuando su puntero dai_name se pasa a strcmp(), da como resultado una desreferencia de puntero nulo y un pánico del kernel. Además de eso, set_card_codec_info() en el archivo de ayuda genérico, mtk-soundcard-driver.c, llenará un enlace dai con un códec ficticio cuando un nodo de enlace dai esté presente en DT pero sin ninguna propiedad de códec. El resultado es que en el momento de la prueba, un códec ficticio puede no estar inicializado con num_codecs = 0, o ser un códec ficticio inicializado, con num_codecs = 1 y dai_name = "snd-soc-dummy-dai". Para tener en cuenta ambas situaciones, verifique que num_codecs no sea cero antes de acceder a los campos de los códecs, pero aún así verifique el nombre dai del códec contra "snd-soc-dummy-dai" según sea necesario. Mientras tanto, también elimine la verificación de que dai_name no sea nulo en el controlador mt8192, introducida en el commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192: Verificar la existencia de dai_name antes de desreferenciar"), ya que en realidad es redundante dada la verificación anterior de num_codecs != 0.