Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: no configure RO al apagar f2fs El apagado no verifica el error de thaw_super debido a solo lectura, lo que causa un punto muerto como el que se muestra a continuación. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issues_discard_thread - bdev_freeze - frozen_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - establecer RO - esperando - bdev_thaw - thaw_super_locked - devolver -EINVAL, si sb_rdonly() - card_thread -> esperar kthread_stop(discard_thread);

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mtk-vcodec: posible deferencia de puntero nulo en SCP Es necesario verificar el valor de retorno de devm_kzalloc() para evitar la deferencia de puntero NULL. Esto es similar a CVE-2022-3113.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: evita una posible desreferencia NULL en rt6_probe() syzbot detectó una desreferencia NULL en rt6_probe() [1] Rescate si __in6_dev_get() devuelve NULL. [1] Ups: falla de protección general, probablemente para la dirección no canónica 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x00000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz- executor.0 No contaminado 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 RIP: 0010:rt6_probe net/ipv6/route.c: 656 [en línea] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Código: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af1 50 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e 18 R14: ffff8880244a1d20 R15: 00000000000000000 FS: 00007f4844a5a6c0(0000) GS :ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000400 Seguimiento de llamadas: rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 net/ipv6/ route.c:853 [en línea] rt6_select net/ipv6/route.c:897 [en línea] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [en línea] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [en línea] ip6_route_output_flags+0x1d0/0x640 net/ipv6 /ruta. c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw. c:898 inet_sendmsg +0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/ read_write.c:497 [en línea] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd /0x250 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6: previene posible deref NULL en fib6_nh_init() syzbot nos recuerda que in6_dev_get() puede devolver NULL. fib6_nh_init() ip6_validate_gw( &idev ) ip6_route_check_nh( idev ) *idev = in6_dev_get(dev); // puede ser NULL Ups: falla de protección general, probablemente para dirección no canónica 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 11237 Co milímetros: syz-executor.3 No está contaminado 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/06/2024 RIP: 0010:fib6_nh_init+0x640/0x2160 net/ ipv6/route.c:3606 Código: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b RSP: 0018:ffffc900032775a0 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8 RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000 R10: 00000000000002fc R11: 0000000000000000 R12: ff88802b3a08b8 R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000 FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) 000000000000 CS: 0010 DS: 0000 ES : 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000 000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c :3809 ip6_route_add+0x28/0x160 net/ipv6/route.c:3853 ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483 inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579 0x158/0x460 neto /socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c :893 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: 0033:0x7f940f07cea9

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mips: bmips: BCM6358: asegúrese de que CBR esté configurado correctamente. Se descubrió que algunos dispositivos tienen la dirección CBR configurada en 0, lo que provoca pánico en el kernel cuando se llama a arch_sync_dma_for_cpu_all. Esto se notó en una situación en la que el sistema se inicia desde TP1 y BMIPS_GET_CBR() devuelve 0 en lugar de una dirección válida y !!(read_c0_brcm_cmt_local() & (1 << 31)); no fallar. La verificación actual de si la descarga de RAC debe desactivarse o no no es suficiente, por lo tanto, verifiquemos si CBR es una dirección válida o no.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: agregue la opción para que un tty rechace un nuevo ldisc... y utilícelo para limitar las terminales virtuales a solo N_TTY. Son algo especiales y, en particular, la rutina "con_write()" viola la regla "las escrituras no pueden dormir" en la que se basan algunos ldiscs. Esto evita el ERROR: función de suspensión llamada desde un contexto no válido en kernel/printk/printk.c:2659 cuando N_GSM se ha conectado a una consola virtual, y gsmld_write() llama a con_write() mientras mantiene un spinlock, y con_write() luego intenta para obtener el bloqueo de la consola.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: imx: Introduce tiempo de espera cuando se espera que el transmisor esté vacío. Esperando como máximo 1 segundo para que se establezca USR2_TXDC, evitamos un posible punto muerto. En caso de que se agote el tiempo de espera, no hay mucho que podamos hacer, por lo que simplemente ignoramos el estado del transmisor e intentamos continuar con optimismo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: Octeon: agregar verificación de estado del enlace PCIe La interfaz de lectura y escritura de configuración PCIe estándar se utiliza para acceder al espacio de configuración de los dispositivos PCIe periféricos del procesador mips después de la sorpresa del enlace PCIe. inactivo, puede generar pánico en el kernel causado por un "Error del bus de datos". Por lo tanto, es necesario agregar una verificación del estado del enlace PCIe para proteger el sistema. Cuando el enlace PCIe está inactivo o en entrenamiento, asignar un valor de 0 a la dirección de configuración puede evitar el comportamiento de lectura y escritura en el espacio de configuración de los dispositivos PCIe periféricos, evitando así el pánico del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Evitar la saturación de la matriz hw_desc en dw-axi-dmac. Tengo un caso de uso donde nr_buffers = 3 y en el que cada descriptor está compuesto por 3 segmentos, lo que da como resultado que el canal DMA descs_allocated sea 9. Dado que axi_desc_put() maneja hw_desc considerando descs_allocated, este escenario provocaría un pánico en el kernel (la matriz hw_desc se desbordará). Para solucionar este problema, la propuesta es agregar un nuevo miembro a la estructura axi_dma_desc, donde mantenemos el número de hw_descs asignados (axi_desc_alloc()) y lo usamos en axi_desc_put() para manejar la matriz hw_desc correctamente. Además, propongo eliminar la llamada axi_chan_start_first_queued() después de completar la transferencia, ya que se identificó que puede ocurrir un desequilibrio (los descriptores iniciados pueden interrumpirse y la transferencia se ignora debido a que el canal DMA no está habilitado).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: eliminar el indicador SB_INLINECRYPT en default_options En f2fs_remount, el indicador SB_INLINECRYPT se borrará y se restablecerá. Si crea un archivo nuevo o abre un archivo durante este intervalo, estos archivos no utilizarán inlinecrypt. En el peor de los casos, puede provocar daños en los datos si Wrappedkey_v0 está habilitado. Hilo A: Hilo B: -f2fs_remount -f2fs_file_open o f2fs_new_inode -default_options <- borrar el indicador SB_INLINECRYPT -fscrypt_select_encryption_impl -parse_options <- configurar SB_INLINECRYPT nuevamente

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: no crear inodo EA bajo bloqueo de búfer ext4_xattr_set_entry() crea nuevos inodos EA mientras mantiene el bloqueo de búfer en el bloque xattr externo. Esto es problemático ya que anida todo el bloqueo de asignación (que adquiere bloqueos en otros búfer) bajo el bloqueo del búfer. Esto puede incluso bloquearse cuando el sistema de archivos está dañado y, por ejemplo, el archivo de cuota está configurado para contener el bloque xattr como bloque de datos. Mueva la asignación del inodo EA de ext4_xattr_set_entry() a las personas que llaman.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: aplica la validez y el tamaño del búfer de resultados de hcall plpar_hcall(), plpar_hcall9() y las funciones relacionadas esperan que los llamadores proporcionen búferes de resultados válidos de cierto tamaño mínimo. Actualmente esto se comunica sólo a través de comentarios en el código y el compilador no tiene idea. Por ejemplo, si escribo un error como este: long retbuf[PLPAR_HCALL_BUFSIZE]; // debería ser PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); Esto se compila sin emitir diagnósticos, pero probablemente da como resultado daños en la pila en tiempo de ejecución cuando plpar_hcall9() almacena los resultados más allá del final de la matriz. (Para ser claros, este es un ejemplo artificial y todavía no he encontrado una instancia real). Para hacer que esta clase de error sea menos probable, podemos usar parámetros de matriz de tamaño explícito en lugar de punteros en las declaraciones de las API hcall. Cuando se compila con -Warray-bounds[1], el código anterior ahora provoca un diagnóstico como este: error: el argumento de la matriz es demasiado pequeño; es de tamaño 32, el destinatario requiere al menos 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Habilitado para compilaciones LLVM pero no para GCC por ahora. Consulte El commit 0da6e5fd6c37 ("gcc: deshabilite '-Warray-bounds' para gcc-13 también") y relacionados cambios.