Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: av7110: se corrige una vulnerabilidad de Spectre Como lo advirtió smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) Hay una vulnerabilidad relacionada con Spectre en el código. Arréglenla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: dvb-core: agregar comprobación de índice de búfer faltante. dvb_vb2_expbuf() no verificaba si el índice de búfer indicado era de un búfer válido. Agregue esta comprobación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: no deje un puntero sk colgando en __smc_create() Gracias a el commit 4bbd360a5084 ("socket: Imprimir pf->create() cuando no borra sock->sk en caso de error."), syzbot encontró un problema con AF_SMC: smc_create debe borrar sock->sk en caso de error, familia: 43, tipo: 1, protocolo: 0 ADVERTENCIA: CPU: 0 PID: 5827 en net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Módulos vinculados: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 No contaminado 6.12.0-rc6-next-20241106-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Código: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 000000000000000 RDI: 000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b860 0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 000000000003526f0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: sock_create net/socket.c:1616 [en línea] __sys_socket_create net/socket.c:1653 [en línea] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [en línea] __se_sys_socket net/socket.c:1712 [en línea] Para referencia, consulte el commit 2d859aff775d ("Fusionar rama 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Se corrige la falta de bloqueo que causa llamadas colgadas Si una llamada se cancela (por ejemplo, porque kafs vio una señal) entre su puesta en cola para la conexión y el hilo de E/S que recoge la llamada, la cancelación tendrá prioridad sobre la conexión y se eliminará de local->new_client_calls mediante rxrpc_disconnect_client_call() sin que se mantenga un bloqueo. Esto puede provocar que otras llamadas de la lista desaparezcan si se produce una ejecución. Arregle esto tomando el client_call_lock al eliminar una llamada de cualquier lista en la que se encuentre su ->wait_link.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: xilinx: axienet: Poner en cola los paquetes Tx en dql antes de que se inicie dmaengine Poner en cola los paquetes en dql después de que se inicie el motor dma provoca una condición de ejecución. La transferencia Tx comienza una vez que se inicia el motor dma y puede ejecutar dql dequeue al finalizar antes de que se ponga en cola. Esto da como resultado el siguiente bloqueo del kernel mientras se ejecuta la prueba de estrés iperf: ¡ERROR del kernel en lib/dynamic_queue_limits.c:99! Error interno: Ups - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Rastreo de llamadas: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Iniciar dmaengine después de poner en cola en dql corrige el fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: enetc: asignar vf_state durante los sondeos de PF En la implementación anterior, a vf_state se le asigna memoria solo cuando VF está habilitado. Sin embargo, se puede llamar a net_device_ops::ndo_set_vf_mac() antes de que VF esté habilitado para configurar la dirección MAC de VF. Si este es el caso, enetc_pf_set_vf_mac() accederá a vf_state, lo que dará como resultado el acceso a un puntero nulo. El registro de errores simplificado es el siguiente. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Mensaje de sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Rastreo de llamada: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: cx24116: evitar desbordamientos en el cálculo de SNR según lo informado por Coverity, si falla la lectura de registros SNR, se devolverá un número negativo, lo que provocará un desbordamiento al leer registros SNR. Evitar eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: stm32: spdifrx: corrige la liberación del canal DMA en stm32_spdifrx_remove En caso de error al solicitar el canal DMA ctrl_chan, ctrl_chan no es nulo. Por lo tanto, la liberación del canal DMA genera el siguiente problema: [4.879000] st,stm32-spdifrx 500d0000.audio-controller: error dma_request_slave_channel -19 [4.888975] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 000000000000003d [...] [5.096577] Rastreo de llamadas: [5.099099] dma_release_channel+0x24/0x100 [5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] Para evitar este problema, libere el canal solo si el puntero es válido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: arc: reparar el dispositivo para dma_map_single/dma_unmap_single ndev->dev y pdev->dev no son el mismo dispositivo, use ndev->dev.parent que tiene dma_mask, ndev->dev.parent es simplemente pdev->dev. O causaría el siguiente problema: [ 39.933526] ------------[ cortar aquí ]------------ [ 39.938414] ADVERTENCIA: CPU: 1 PID: 501 en kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: se corrige el fallo del kernel al desinstalar el controlador Cuando se desinstala el controlador y se deshabilita el VF al mismo tiempo, se produce un fallo del kernel. La razón es que las dos acciones llaman a la función pci_disable_sriov(). Se comprueba num_VFs para determinar si se deben liberar los recursos correspondientes. Durante la segunda llamada, num_VFs no es 0 y se llama a la función de liberación de recursos. Sin embargo, el recurso correspondiente se ha liberado durante la primera invocación. Por lo tanto, se produce el problema: [15277.839633][T50670] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000020 ... [15278.131557][T50670] Rastreo de llamadas: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_detener_y_eliminar_dispositivo_bus+0x6c/0x80 [15278.157447][T50670] pci_iov_eliminar_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_deshabilitar+0x50/0x11c [15278.166829][T50670] pci_deshabilitar_sriov+0x24/0x30 [15278.171433][T50670] hnae3_anular_registro_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invocar_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 Para obtener más detalles, consulte la siguiente figura. rmmod hclge deshabilitar VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() si !num_VFs: si !num_VFs: devolver; devolver; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); En este parche, cuando se elimina el controlador, obtenemos device_lock() para proteger num_VFs, al igual que sriov_numvfs_store().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm: corrige un bloqueo si blk_alloc_disk falla Si blk_alloc_disk falla, la variable md->disk se establece en un valor de error. cleanup_mapped_device verá que md->disk no es NULL e intentará acceder a él, lo que provocará un bloqueo en esta declaración "md->disk->private_data = NULL;".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: trusted: dcp: fix NULL dereference in AEAD cryptooperation Al sellar o desellar un blob de claves, actualmente no esperamos a que finalice la operación de cifrado AEAD y simplemente regresamos después de enviar la solicitud. Si hay alguna carga en el sistema, podemos salir antes de que finalice la operación de cifrado y el búfer desde el que leemos/escribimos ya se eliminó de la pila. Esto, por ejemplo, dará como resultado errores de desreferencia de puntero NULL en el controlador DCP durante la creación del blob. Solucione esto esperando a que finalice la operación de cifrado AEAD antes de reanudar las llamadas de sellado y dessellado.