Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: Evitar recuento incorrecto para tracing_cpumask_write Si se proporciona un recuento alto, se activará una advertencia en bitmap_parse_user. También verifique que esté a cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ublk: separar gendisk del dispositivo ublk si add_disk() falla Dentro de ublk_abort_requests(), gendisk se toma para abortar todas las solicitudes en vuelo. Y ublk_abort_requests() se llama al salir del contexto uring o al gestionar el tiempo de espera. Si add_disk() falla, es posible que gendisk se haya liberado al llamar a ublk_abort_requests(), por lo que se puede producir un use-after-free al obtener la referencia del disco en ublk_abort_requests(). Corrige el error separando gendisk del dispositivo ublk si add_disk() falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries/vas: Agregar devolución de llamada close() en la estructura vas_vm_ops La dirección VMA de asignación se guarda en la estructura de la ventana VAS cuando se asigna la dirección de pegado. Esta dirección VMA se utiliza durante la migración para anular la asignación de la dirección de pegado si la ventana está activa. La asignación de la dirección de pegado se eliminará cuando se cierre la ventana o con munmap(). Pero la dirección VMA en la ventana VAS no se actualiza con munmap(), lo que provoca un acceso no válido durante la migración. El informe de KASAN muestra: [16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8 [16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928 [16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G B 6.11.0-rc5-nxgzip #2 [16386.255128] Tainted: [B]=BAD_PAGE [16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries [16386.255181] Call Trace: [16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable) [16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764 [16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8 [16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0 [16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8 [16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc [16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4 ... [16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s: [16386.256149] kasan_save_stack+0x34/0x68 [16386.256163] kasan_save_track+0x34/0x80 [16386.256175] kasan_save_alloc_info+0x58/0x74 [16386.256196] __kasan_slab_alloc+0xb8/0xdc [16386.256209] kmem_cache_alloc_noprof+0x200/0x3d0 [16386.256225] vm_area_alloc+0x44/0x150 [16386.256245] mmap_region+0x214/0x10c4 [16386.256265] do_mmap+0x5fc/0x750 [16386.256277] vm_mmap_pgoff+0x14c/0x24c [16386.256292] ksys_mmap_pgoff+0x20c/0x348 [16386.256303] sys_mmap+0xd0/0x160 ... [16386.256350] Freed by task 0 on cpu 31 at 16386.204848s: [16386.256363] kasan_save_stack+0x34/0x68 [16386.256374] kasan_save_track+0x34/0x80 [16386.256384] kasan_save_free_info+0x64/0x10c [16386.256396] __kasan_slab_free+0x120/0x204 [16386.256415] kmem_cache_free+0x128/0x450 [16386.256428] vm_area_free_rcu_cb+0xa8/0xd8 [16386.256441] rcu_do_batch+0x2c8/0xcf0 [16386.256458] rcu_core+0x378/0x3c4 [16386.256473] handle_softirqs+0x20c/0x60c [16386.256495] do_softirq_own_stack+0x6c/0x88 [16386.256509] do_softirq_own_stack+0x58/0x88 [16386.256521] __irq_exit_rcu+0x1a4/0x20c [16386.256533] irq_exit+0x20/0x38 [16386.256544] interrupt_async_exit_prepare.constprop.0+0x18/0x2c ... [16386.256717] Last potentially related work creation: [16386.256729] kasan_save_stack+0x34/0x68 [16386.256741] __kasan_record_aux_stack+0xcc/0x12c [16386.256753] __call_rcu_common.constprop.0+0x94/0xd04 [16386.256766] vm_area_free+0x28/0x3c [16386.256778] remove_vma+0xf4/0x114 [16386.256797] do_vmi_align_munmap.constprop.0+0x684/0x870 [16386.256811] __vm_munmap+0xe0/0x1f8 [16386.256821] sys_munmap+0x54/0x6c [16386.256830] system_call_exception+0x1a0/0x4a0 [16386.256841] system_call_vectored_common+0x15c/0x2ec [16386.256868] The buggy address belongs to the object at c00000014a819670 which belongs to the cache vm_area_struct of size 168 [16386.256887] The buggy address is located 0 bytes inside of freed 168-byte region [c00000014a819670, c00000014a819718) [16386.256915] The buggy address belongs to the physical page: [16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81 [16386.256950] memcg:c0000000ba430001 [16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff) [16386.256975] page_type: 0xfdffffff(slab) [16386 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/MSI: gestionar la falta de irqdomain con gracia Alexandre observó una advertencia emitida desde pci_msi_setup_msi_irqs() en una plataforma RISCV que no proporciona compatibilidad con PCI/MSI: ADVERTENCIA: CPU: 1 PID: 1 en drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32 __pci_enable_msix_range+0x30c/0x596 pci_msi_setup_msi_irqs+0x2c/0x32 pci_alloc_irq_vectors_affinity+0xb8/0xe2 RISCV utiliza dominios de interrupción jerárquicos y no implementa correctamente el respaldo heredado. La advertencia se activa desde el stub de respaldo heredado. Esa advertencia es falsa, ya que la capa PCI/MSI sabe si un dominio principal PCI/MSI está asociado con el dispositivo o no. Hay una comprobación para MSI-X, que tiene una suposición de legado. Pero esa suposición de respaldo heredado solo es válida cuando está habilitada la compatibilidad heredada, pero de lo contrario, la comprobación simplemente debería devolver -ENOTSUPP. Loongarch tropezó con el mismo problema y habilitó ciegamente la compatibilidad heredada sin implementar los respaldos heredados. Hay implementaciones débiles que devuelven un error, por lo que el problema se disimuló. Corrija pci_msi_domain_supports() para evaluar el modo heredado y agregue la comprobación de compatibilidad faltante en la ruta de habilitación de MSI para completarla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fred: Borrar WFE en #CPs de ENDBRANCH faltantes Una instrucción de bifurcación indirecta establece el rastreador de bifurcación indirecta (IBT) de la CPU en estado WAIT_FOR_ENDBRANCH (WFE) y WFE permanece afirmado a través del límite de instrucción. Cuando el decodificador encuentra una instrucción inapropiada mientras WFE está establecido en ENDBR, la CPU genera un error #CP. Para la autoprueba "IBT del kernel sin ENDBR" donde los #CP se activan deliberadamente, el estado WFE del contexto interrumpido debe borrarse para permitir que la ejecución continúe. De lo contrario, cuando la CPU se reanuda desde la instrucción que acaba de causar el #CP anterior, se genera otro #CP de ENDBRANCH faltante y la CPU entra en un bucle muerto. Esto no es un problema con IDT porque no preserva WFE e IRET no establece WFE. Pero FRED proporciona espacio en la pila de entrada (en un área CS expandida) para guardar y restaurar el estado WFE, por lo que el estado WFE ya no se ve afectado, por lo que el software debe limpiarlo. Limpie WFE para evitar bucles muertos en ibt_clear_fred_wfe() y la ruta de código !ibt_fatal cuando se permite que la ejecución continúe. Afectar a WFE en cualquier otra circunstancia es un error relevante para la seguridad. [ dhansen: reformulación del registro de cambios ]

Motivo del rechazo: esta ID CVE ha sido rechazada o retirada por su autoridad de numeración CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btusb: mediatek: agregar flujo de liberación de intf cuando se desconecta el USB MediaTek reclama una interfaz USB intr especial para la transmisión de datos ISO. La interfaz debe liberarse antes de anular el registro del dispositivo HCI cuando se desconecta el USB. Quitar el dispositivo USB BT sin liberar correctamente la interfaz puede provocar un pánico del kernel al anular el registro del dispositivo HCI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el use-after-free cuando se aplica COW a un bloque de árbol y se habilita el seguimiento Cuando se aplica COW a un bloque de árbol, en btrfs_cow_block(), y tenemos habilitado el punto de seguimiento trace_btrfs_cow_block() y también está habilitada la preempción (CONFIG_PREEMPT=y), podemos activar un use-after-free en el búfer de extensión aplicado COW mientras estamos dentro del código del punto de seguimiento. Esto se debe a que en algunas rutas que llaman a btrfs_cow_block(), como btrfs_search_slot(), estamos manteniendo la última referencia en el búfer de extensión @buf, por lo que btrfs_force_cow_block() elimina la última referencia en el búfer de extensión @buf cuando llama a free_extent_buffer_stale(buf), que programa la liberación del búfer de extensión con RCU. Esto significa que si estamos en un núcleo con preempción, la tarea actual puede ser preemptada antes de llamar a trace_btrfs_cow_block() y el buffer de extensión ya liberado para el momento en que se llama a trace_btrfs_cow_block(), lo que da como resultado un use-after-free. Arregle esto moviendo trace_btrfs_cow_block() de btrfs_cow_block() a btrfs_force_cow_block() antes de que se libere el buffer de extensión COWed. Esto también tiene un efecto secundario de invocar el punto de seguimiento en el código de desfragmentación del árbol, en defrag.c:btrfs_realloc_node(), ya que btrfs_force_cow_block() se llama allí, pero esto está bien y en realidad faltaba allí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: comprobar la asignación de folios después de desbloquear en relocate_one_folio() Cuando llamamos a btrfs_read_folio() para actualizar un folio, desbloqueamos el folio. El resultado de eso es que un hilo diferente puede modificar la asignación (como eliminarla con invalidate) antes de que llamemos a folio_lock(). Esto da como resultado una página no válida y debemos volver a intentarlo. En particular, si estamos reubicando simultáneamente y abortando una transacción, esto puede resultar en un bloqueo como el siguiente: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 76 PID: 1411631 Comm: kworker/u322:5 Workqueue: events_unbound btrfs_reclaim_bgs_work RIP: 0010:set_page_extent_mapped+0x20/0xb0 RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246 RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880 RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0 R10: 000000000000000 R11: 0000194754b575be R12: 0000000003572000 R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __die+0x78/0xc0 ? page_fault_oops+0x2a8/0x3a0 ? __switch_to+0x133/0x530 ? wq_worker_running+0xa/0x40 ? exc_page_fault+0x63/0x130 ? asm_exc_page_fault+0x22/0x30 ? blk_add_timer+0xb0/0xb0 kthread+0xae/0xe0 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork+0x2f/0x40 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork_asm+0x11/0x20 Esto ocurre porque cleanup_one_transaction() llama a destroy_delalloc_inodes() que llama a invalidate_inode_pages2() que toma el folio_lock antes de establecer mapping en NULL. No comprobamos esto y, posteriormente, llamamos a set_extent_mapping(), que supone que mapping != NULL (de hecho, lo afirma en modo de depuración). Tenga en cuenta que el parche de "correcciones" aquí no es el que introdujo la ejecución(la primera iteración de este código de 2009), sino un cambio más reciente que hizo que este fallo en particular sucediera en la práctica.

Suricata es un sistema de detección de intrusiones, un sistema de prevención de intrusiones y un motor de monitoreo de seguridad de red. Antes de la versión 7.0.8, un búfer de entrada grande en to_lowercase, to_uppercase, strip_whitespace, compress_whitespace, dotprefix, header_lowercase, strip_pseudo_headers, url_decode o la transformación xor puede generar un desbordamiento de pila que haga que Suricata se bloquee. El problema se ha solucionado en Suricata 7.0.8.

IBM UrbanCode Deploy (UCD) 7.2 a 7.2.3.13, 7.3 a 7.3.2.8 e IBM DevOps Deploy 8.0 a 8.0.1.3 son vulnerables a la inyección de HTML. Esta vulnerabilidad puede permitir que un usuario incorpore etiquetas HTML arbitrarias en la interfaz de usuario web, lo que podría provocar la divulgación de información confidencial.

Dell PowerScale OneFS 8.2.2.x a 9.8.0.x contiene una asignación de permisos incorrecta para una vulnerabilidad de recursos críticos. Un atacante autenticado localmente podría aprovechar esta vulnerabilidad, lo que provocaría una denegación de servicio.