Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPICA: Revertir "ACPICA: evitar Información: mapeo de múltiples BAR. Su kernel está bien". Deshaga las modificaciones realizadas en el commit d410ee5109a1 ("ACPICA: evite "Información: mapeo de varias BAR. Su kernel está bien.""). El propósito inicial de esté commit fue evitar que las asignaciones de memoria para regiones de operación se superpongan en los límites de las páginas, ya que puede generar advertencias si hay diferentes atributos de página presentes. Sin embargo, se descubrió que cuando surge esta situación, el mapeo continúa hasta el final del límite, pero todavía hay un intento de leer/escribir en toda la longitud del mapa, lo que lleva a una deferencia del puntero NULL. Por ejemplo, si se realiza una solicitud de asignación de cuatro bytes pero solo se asigna un byte porque llega al final del límite de la página actual, aún se realiza un intento de lectura/escritura de cuatro bytes, lo que resulta en una deferencia de puntero NULL. En su lugar, asigne toda la longitud, ya que la especificación ACPI no exige que deba estar dentro del mismo límite de página. Está permitido mapearlo en diferentes regiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zonificado: asigna sumas de verificación ficticias para zonas zonificadas NODATASUM escribe Shin'ichiro informó que cuando ejecuta el caso de prueba btrfs/167 de fstests en dispositivos zonificados emulados, ve el siguiente puntero NULL desreferencia en 'btrfs_zone_finish_endio()': Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000088-0x00000000000000 8f] CPU: 4 PID: 2332440 Comm: kworker/u80:15 Contaminado: GW 6.10.0-rc2-kts+ #4 Nombre de hardware: Supermicro Super Server/X11SPi-TF, BIOS 3.3 21/02/2020 Cola de trabajo: btrfs-endio-write btrfs_work_helper [btrfs] RIP : 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] RSP: 0018:ffff88867f107a90 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 893e5534 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: 6028 R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000 R13: 0000000000020000 R14: 00000000000000000 R15: ffff888530ad5210 FS: 0000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f87223fff38 CR3 : 00000007a7c6a002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? die_addr+0x46/0x70? exc_general_protection+0x14f/0x250? asm_exc_general_protection+0x26/0x30? do_raw_read_unlock+0x44/0x70? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] btrfs_finish_one_ordered+0x5d9/0x19a0 [btrfs] ? __pfx_lock_release+0x10/0x10? do_raw_write_lock+0x90/0x260? __pfx_do_raw_write_lock+0x10/0x10? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]? _raw_write_unlock+0x23/0x40? btrfs_finish_ordered_zoned+0x5a9/0x850 [btrfs]? lock_acquire+0x435/0x500 btrfs_work_helper+0x1b1/0xa70 [btrfs]? __programar+0x10a8/0x60b0? __pfx___might_resched+0x10/0x10 proceso_one_work+0x862/0x1410 ? __pfx_lock_acquire+0x10/0x10? __pfx_process_one_work+0x10/0x10? asignar_trabajo+0x16c/0x240 trabajador_hilo+0x5e6/0x1010? __pfx_worker_thread+0x10/0x10 kthread+0x2c3/0x3a0 ? trace_irq_enable.constprop.0+0xce/0x110? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Al habilitar CONFIG_BTRFS_ASSERT se reveló la siguiente aserción para activar: aserción fallida: !list_empty(&ordered->list), en fs/btrfs/zoned.c:1815 Esto indica que Falta la lista de sumas de verificación en la extensión_ordenada. Como btrfs/167 está escribiendo NOCOW, esto es de esperarse. Un análisis más detallado con drgn confirmó la suposición: >>> inode = prog.crashed_thread().stack_trace()[11]['ordered'].inode >>> btrfs_inode = drgn.container_of(inode, "struct btrfs_inode", \ " vfs_inode") >>> print(btrfs_inode.flags) (u32)1 Como el modo de emulación de zonas simula zonas convencionales en dispositivos normales, no podemos usar Zone-Append para escribir. Pero solo adjuntamos sumas de verificación ficticias si realizamos una escritura de adición de zona. Entonces, para las escrituras de datos de zonas NOCOW en zonas convencionales, adjunte también una suma de verificación ficticia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: cs35l41: Posible desreferencia del puntero nulo en cs35l41_hda_unbind() La función cs35l41_hda_unbind() borra la entrada hda_component que coincide con su índice y luego desreferencia el puntero del códec contenido en el primer elemento de la matriz hda_component, esto es un problema cuando el índice del dispositivo era 0. En su lugar, utilice el puntero del códec escondido en la estructura cs35l41_hda, ya que seguirá siendo válido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: lpi2c: evite llamar a clk_get_rate durante la transferencia. En lugar de llamar repetidamente a clk_get_rate para cada transferencia, bloquee la velocidad del reloj y almacene en caché el valor. Se ha observado un punto muerto al agregar el códec de audio tlv320aic32x4 al sistema. Cuando este proveedor de reloj agrega su reloj, el mutex clk ya está bloqueado, necesita acceder a i2c, que a cambio también necesita el mutex para clk_get_rate.

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.