Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: security/keys: corrección de slab-out-of-bounds en key_task_permission KASAN informa una lectura fuera de los límites: ERROR: KASAN: slab-out-of-bounds en __kuid_val include/linux/uidgid.h:36 ERROR: KASAN: slab-out-of-bounds en uid_eq include/linux/uidgid.h:63 [en línea] ERROR: KASAN: slab-out-of-bounds en key_task_permission+0x394/0x410 security/keys/permission.c:54 Lectura de tamaño 4 en la dirección ffff88813c3ab618 por la tarea stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng No contaminado 5.10.0-14930-gafbffd6c3ede #15 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:82 [en línea] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [en línea] uid_eq include/linux/uidgid.h:63 [en línea] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 Este problema también fue informado por syzbot. Puede reproducirse siguiendo estos pasos (más detalles [1]): 1. Obtenga más de 32 entradas que tengan hashes similares, que terminen con el patrón '0xxxxxxxe6'. 2. Reinicie y agregue las claves obtenidas en el paso 1. El reproductor demuestra cómo sucedió este problema: 1. En la función search_nested_keyrings, cuando itera a través de las ranuras en un nodo (debajo de la etiqueta ascend_to_node), si el puntero de la ranura es meta y node->back_pointer != NULL (significa una raíz), procederá a descend_to_node. Sin embargo, hay una excepción. Si el nodo es la raíz y una de las ranuras apunta a un acceso directo, se tratará como un llavero. 2. Si el ptr es un llavero lo decide la función keyring_ptr_is_keyring. Sin embargo, KEYRING_PTR_SUBTYPE es 0x2UL, lo mismo que ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. Cuando se agregan 32 claves con hashes similares al árbol, la RAÍZ tiene claves con hashes que no son similares (por ejemplo, la ranura 0) y divide el NODO A sin usar un acceso directo. Cuando el NODO A se llena con claves en las que todos los hashes son xxe6, las claves son similares, el NODO A se dividirá con un acceso directo. Finalmente, forma el árbol como se muestra a continuación, donde la ranura 6 apunta a un acceso directo. NODO A +------>+---+ RAÍZ | | 0 | xxe6 +---+ | +---+ xxxx | 0 | acceso directo : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. Como se mencionó anteriormente, si una ranura (ranura 6) de la raíz apunta a un acceso directo, puede transferirse por error a una clave*, lo que lleva a una lectura fuera de los límites. Para solucionar este problema, uno debe saltar a descend_to_node si el ptr es un acceso directo, independientemente de si el nodo es raíz o no. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: modifiqué un poco el mensaje de confirmación para tener una etiqueta de cierre apropiada].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: núcleo: inicializar en cero el búfer de informes Dado que el búfer de informes es utilizado por todo tipo de controladores de diversas formas, vamos a inicializarlo en cero durante la asignación para asegurarnos de que nunca pueda usarse para filtrar memoria del kernel a través de un informe especialmente manipulado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vivid: se corrige la sobrescritura de búfer al usar > 32 búferes. La cantidad máxima de búferes que se pueden solicitar se aumentó a 64 para la cola de captura de video. Pero la captura de video usó una matriz must_blank que todavía tenía un tamaño de 32 (VIDEO_MAX_FRAME). Esto provocó una escritura fuera de los límites cuando se usan índices de búfer >= 32. Cree una nueva definición MAX_VID_CAP_BUFFERS que se use para acceder a la matriz must_blank y establezca max_num_buffers para la cola de captura de video. Esto resuelve un bloqueo informado por: https://bugzilla.kernel.org/show_bug.cgi?id=219258

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