Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: corrige un MCE irrecuperable que llama al controlador asíncrono desde NMI. El controlador de verificación de la máquina no se considera NMI en 64s. El controlador inicial es el verdadero controlador NMI y luego programa el controlador machine_check_exception para que se ejecute cuando las interrupciones estén habilitadas. Esto funciona bien excepto en el caso de un MCE irrecuperable, donde el NMI verdadero se toma cuando MSR[RI] está claro, no se puede recuperar, por lo que llama a machine_check_exception directamente para que se pueda hacer algo al respecto. Llamar a un controlador asíncrono desde el contexto NMI puede provocar que el estado irq y otras cosas se corrompan. Esto también puede desencadenar el ERROR en arch/powerpc/include/asm/interrupt.h:168 BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE)); Solucione este problema creando una versión _async del controlador que se llama en el caso normal, y una versión NMI que se llama para interrupciones irrecuperables.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/entry: borra X86_FEATURE_SMAP cuando CONFIG_X86_SMAP=n confirmación 3c73b81a9164 ("x86/entry, selftests: mejora aún más las comprobaciones de seguridad de entrada del usuario") agregó una advertencia si AC está configurado en el núcleo. La confirmación 662a0221893a3d ("x86/entry: Reparar aserción de AC") cambió la advertencia para que solo se active si la CPU admite SMAP. Sin embargo, la advertencia aún puede activarse en una máquina que admite SMAP pero donde está deshabilitado en la configuración del kernel y cuando se ejecuta la autoprueba syscall_nt, por ejemplo: ------------[ cortar aquí ]--- --------- ADVERTENCIA: CPU: 0 PID: 49 en irqentry_enter_from_user_mode CPU: 0 PID: 49 Comm: init Tainted: GT 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 01/04/2014 RIP: 0010:irqentry_enter_from_user_mode... Seguimiento de llamadas:? irqentry_enter? exc_general_protection? asm_exc_general_protection? Se podría agregar asm_exc_general_protectio IS_ENABLED(CONFIG_X86_SMAP) a la condición de advertencia, pero incluso esto no sería suficiente en caso de que SMAP esté deshabilitado en el momento del arranque con el parámetro "nosmap". Para ser coherente con el comportamiento de "nosmap", borre X86_FEATURE_SMAP cuando !CONFIG_X86_SMAP. Encontrado usando Entry-fuzz + satrandconfig. [pb: mensaje de confirmación de masaje. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige la fuga de pin_count de gart.bo gmc_v{9,10}_0_gart_disable() no se llama y coincide con la función gart_enbale correspondiente en el caso SRIOV. Esto provocará una pérdida de pin_count de gart.bo al descargar el controlador.

Una vulnerabilidad de Cross Site Scripting Almacenado (XSS) en la característica "Importación de rol de usuario y título de rol de usuario" en ILIAS 7 anterior a 7.30 e ILIAS 8 anterior a 8.11 permite a atacantes remotos autenticados con privilegios administrativos inyectar scripts web o HTML de su elección mediante la carga de archivos XML.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: mdio: arreglar pérdida de memoria. Syzbot informó una pérdida de memoria en la interfaz del bus MDIO, el problema estaba en una lógica de estado incorrecta. MDIOBUS_ALLOCATED indica 2 estados: 1. El bus solo está asignado 2. El bus asignado y __mdiobus_register() falla, pero se llamó a device_register() En caso de que se haya llamado a device_register() debemos llamar a put_device() para liberar correctamente la memoria asignada para esto dispositivo, pero mdiobus_free() llama solo a kfree(dev) en caso de estado MDIOBUS_ALLOCATED. Para evitar este comportamiento, necesitamos configurar bus->state en MDIOBUS_UNREGISTERED _antes_ de llamar a device_register(), porque put_device() debe llamarse incluso en caso de fallo de device_register( .

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libbpf: repara la pérdida de memoria en strset Libera la estructura strset en sí, no solo sus partes internas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net_sched: corrige el deref NULL en fifo_set_limit() syzbot informó otro deref NULL en fifo_set_limit() [1] Podría reproducir el problema con: unshare -n tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit tc qd reemplazar dev lo parent 1:0 pfifo_fast tc qd cambiar dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit pfifo_fast no tiene una operación de cambio(). Haga que fifo_set_limit() sea más sólido al respecto. [1] BUG: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0 Ups: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 14443 Comm: syz-executor959 No contaminado 5. 15.0-rc3- syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Código: No se puede acceder a los bytes del código de operación en RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: c27910 RDI: ffff888071e34000 RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947 R10: 00000000000000001 R11: 0000000000000000 R12 : ffff888024c27910 R13: ffff888071e34018 R14: 00000000000000000 R15: ffff88801ef74800 FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 50033 CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: fifo_set_limit net/sched/sch_fifo.c:242 [en línea] fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227 6ec/0x16d0 net/sched/sch_tbf.c: 418 qdisc_change net/sched/sch_api.c:1332 [en línea] tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x42 0 red/enlace de red /af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/ socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0 x1b0 neto /socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_taprio: cancelar correctamente el temporizador de taprio_destroy(). Hay un comentario en qdisc_create() acerca de que no llamamos a ops->reset() en algunos casos. err_out4: /* * ¿Alguna qdisc rota que requiera un ops->reset() aquí? * La qdisc nunca estuvo en acción por lo que no debería ser necesaria. */ Como taprio establece un temporizador antes de recibir un paquete, debemos cancelarlo desde ops->destroy, en caso de que no se haya llamado a ops->reset. syzbot informó: ODEBUG: libre activo (estado activo 0) tipo de objeto: hrtimer sugerencia: advanced_sched+0x0/0x9a0 arch/x86/include/asm/atomic64_64.h:22 ADVERTENCIA: CPU: 0 PID: 8441 en lib/debugobjects.c :505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Módulos vinculados en: CPU: 0 PID: 8441 Comm: syz-executor813 No contaminado 5.14.0-rc6-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 01/01/2011 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Código: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 d3 e3 89 4c 89 ee 48 c7 c7 e0 c7 e3 89 e8 5b 86 11 05 <0f> 0b 83 05 85 03 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP 0018:ffff c9000130f330 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 00000000000000003 RCX: 0000000000000000 RDX: ffff88802baeb880 RSI: ffffffff815d87b5 RDI: fffff52000261e58 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815d25ee R11: 00000000000000000 R12: ffffffff898dd020 R13: 3ce20 R14: ffffffff81653630 R15: dffffc0000000000 FS: 0000000000f0d300( 0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffb64b3e000 CR3: 557000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 7: 0000000000000400 Seguimiento de llamadas: __debug_check_no_obj_freed lib/debugobjects.c:987 [en línea] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018 slab_free_hook mm/slub.c:1603 [en línea] slab_free_freelist_hook+0x171/0x240 mm/ slub.c:1653 slab_libre mm/slub.c:3213 [en línea] kfree+0xe4/0x540 mm/slub.c:4267 qdisc_create+0xbcf/0x1320 net/sched/sch_api.c:1299 tc_modify_qdisc+0x4c8/0x1a60 net/sched/sch_api.c:1663 rtnetlink_rcv_msg+0x413/0xb80 nore/rtnetlink.c: 5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c: 2504 netlink_unicast_kernel net/netlink/af_netlink.c: 1314 [netlin /0x7d0 net/netlink/ af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net /zócalo .c:2403 ___sys_sendmsg+0xf3/0x170 net/socket.c:2457 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] arco/ x86/entrada/common.c:80

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: soluciona una posible pérdida de memoria de ttm->sg. La memoria se asigna para ttm->sg mediante kmalloc en kfd_mem_dmamap_userptr, pero kfree no la libera en kfd_mem_dmaunmap_userptr. ¡Libérala!

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau/kms/nv50-: corrige la pérdida de memoria de liberación de archivos. Cuando se usa single_open() para abrir, se debe llamar a single_release(); de lo contrario, se debe llamar a la 'op' asignada en single_open( ) se filtrará.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau/debugfs: corrige la pérdida de memoria de liberación de archivos. Cuando se usa single_open() para abrir, se debe llamar a single_release(); de lo contrario, se ejecutará la 'op' asignada en single_open(). filtrado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: Se corrigió la liberación de un vector IRQ misceláneo no inicializado. Cuando la configuración de VSI falló en i40e_probe() como parte de la configuración del conmutador PF, el controlador intentaba liberar vectores IRQ misceláneos en i40e_clear_interrupt_scheme y produjo un kernel Oops: Intentando liberar IRQ 266 que ya está libre ADVERTENCIA: CPU: 0 PID: 5 en kernel/irq/manage.c:1731 __free_irq+0x9a/0x300 Cola de trabajo: eventos work_for_cpu_fn RIP: 0010:__free_irq+0x9a/0x300 Seguimiento de llamadas: ? synchronize_irq+0x3a/0xa0 free_irq+0x2e/0x60 i40e_clear_interrupt_scheme+0x53/0x190 [i40e] i40e_probe.part.108+0x134b/0x1a40 [i40e] ? kmem_cache_alloc+0x158/0x1c0? acpi_ut_update_ref_count.part.1+0x8e/0x345? acpi_ut_update_object_reference+0x15e/0x1e2? chain+0x21/0x70 ? irq_get_irq_data+0xa/0x20 ? mp_check_pin_attr+0x13/0xc0? irq_get_irq_data+0xa/0x20 ? mp_map_pin_to_irq+0xd3/0x2f0? acpi_register_gsi_ioapic+0x93/0x170? pci_conf1_read+0xa4/0x100? pci_bus_read_config_word+0x49/0x70? do_pci_enable_device+0xcc/0x100 local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 Process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40 El problema es que en ese momento aún no se habían asignado varios vectores IRQ y obtenemos un seguimiento de llamada de que el controlador está intentando liberar vectores IRQ que ya están libres. Agregue una verificación en i40e_clear_interrupt_scheme para el estado __I40E_MISC_IRQ_REQUESTED PF antes de llamar a i40e_free_misc_vector. Este estado se establece solo si se inicializaron correctamente varios vectores IRQ.