Vulnerabilidades

La vulnerabilidad de desbordamiento de búfer basado en montón en RTI Connext Professional (Core Libraries) permite variables y etiquetas de desbordamiento. Este problema afecta a Connext Professional: desde 7.4.0 hasta 7.5.0, desde 7.0.0 hasta 7.3.0.7, desde 4.4 hasta 6.1.2.23.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: sun50i: evitar acceso fuera de los límites Un kernel habilitado para KASAN informa un acceso fuera de los límites al manejar la celda nvmem en el controlador cpufreq sun50i: ======================================================================== ERROR: KASAN: slab-out-of-bounds en sun50i_cpufreq_nvmem_probe+0x180/0x3d4 Lectura de tamaño 4 en la dirección ffff000006bf31e0 por la tarea kworker/u16:1/38 Esto se debe a que el DT especifica que la celda nvmem cubre solo dos bytes, pero usamos u32 Puntero para leer el valor. Los DT de otros SoCs especifican 4 bytes, por lo que no podemos acortar la variable a u16. Afortunadamente, nvmem_cell_read() permite devolver la longitud de la celda nvmem, en bytes, lo que nos permite usar esa información para acceder únicamente a la parte válida de los datos. Para abarcar varios tamaños de celda, use memcpy() para copiar la información a un búfer u32 con ceros. Asegúrese también de leer siempre los datos en formato little endian, ya que así es como se almacenan en los efuses SID.

El complemento WP SEO Structured Data Schema para WordPress es vulnerable a Cross-Site Scripting almacenado a través del parámetro "Rango de precios" en todas las versiones hasta la 2.7.11 incluida, debido a una depuración de entrada y un escape de salida insuficientes. Esto permite a atacantes autenticados, con acceso de colaborador o superior, inyectar scripts web arbitrarios que se ejecutan cada vez que un administrador accede a la página de configuración del complemento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: apple-soc: Se corrige null-ptr-deref en apple_soc_cpufreq_get_rate() cpufreq_cpu_get_raw() puede devolver NULL cuando la CPU de destino no está presente en la máscara policy->cpus. apple_soc_cpufreq_get_rate() no verifica este caso, lo que da como resultado una desreferencia de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: scpi: Corregir null-ptr-deref en scpi_cpufreq_get_rate() cpufreq_cpu_get_raw() puede devolver NULL cuando la CPU de destino no está presente en la máscara policy->cpus. scpi_cpufreq_get_rate() no verifica este caso, lo que da como resultado una desreferencia de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: mcq: Agregar comprobación NULL en ufshcd_mcq_abort() Puede ocurrir una ejecución entre la ruta de finalización de MCQ y el controlador de aborto: una vez que se completa una solicitud, __blk_mq_free_request() establece rq->mq_hctx en NULL, lo que significa que la llamada ufshcd_mcq_req_to_hwq() posterior en ufshcd_mcq_abort() puede devolver un puntero NULL. Si se desreferencia este puntero NULL, el kernel se bloqueará. Agregue una comprobación NULL para el puntero hwq devuelto. Si hwq es NULL, registre un error y devuelva FAILED, lo que evita una posible desreferencia de puntero NULL. Como sugirió Bart, se elimina la comprobación ufshcd_cmd_inflight(). Esto es similar a la corrección en el commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). Esta corrección la encontró nuestra herramienta de análisis estático Knighter.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/niu: Niu requiere que los campos ENTRY_DATA de MSIX se toquen antes de leer la entrada. Corrija niu_try_msix() para que no cause una trampa fatal en sistemas sparc. Establezca PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST en la estructura pci_dev para solucionar un error en el hardware o firmware. Para cada entrada de vector en la tabla msix, los chips niu causarán una trampa fatal si se lee algún registro en esa entrada antes de que se escriba en el registro ENTRY_DATA de esa entrada. Las pruebas indican que las escrituras en otros registros no son suficientes para evitar la trampa fatal; sin embargo, el valor no parece importar. Esto solo necesita suceder una vez después del encendido, por lo que simplemente reiniciar en un kernel que no tenga esta corrección NO causará la trampa. ERROR NO REANUDABLE: Informe de CPU 64 ERROR NO REANUDABLE: TPC [0x00000000005f6900] ERROR NO REANUDABLE: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff ERROR NO REANUDABLE: 0000000800000000:00000000000000000:00000000000000000:00000000000000000] ERROR NO REANUDABLE: handle [0x4010000000000016] stick [0x00000e37f93e32ff] ERROR NO REANUDABLE: tipo [precise nonresumable] ERROR NO REANUDABLE: attrs [0x02000080] < ASI sp-faulted priv > ERROR NO REANUDABLE: raddr [0xffffffffffffffff] ERROR NO REANUDABLE: dirección efectiva insn [0x000000c50020000c] ERROR NO REANUDABLE: tamaño [0x8] ERROR NO REANUDABLE: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 No contaminado 6.11.5 #63 Cola de trabajo: eventos work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 No contaminado TPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 00000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 000000000000000000000000000000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: Rastreo de llamadas: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] workers_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Pánico del kernel: no se sincroniza: Error no reanudable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmscan: no intente reclamar el folio hwpoison Syzkaller informa un error de la siguiente manera: Error de inyección de memoria para pfn 0x18b00e en la dirección virtual del proceso 0x20ffd000 Error de memoria: 0x18b00e: 2 usuarios aún hacen referencia a la página de swapcache sucia Error de memoria: 0x18b00e: acción de recuperación para la página de swapcache sucia: Página con errores: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(bloqueado|sucio|arch_1|swapbacked|hwpoison|nodo=0|zona=2|lastcpupid=0xfffff) sin procesar: 005ffffe00482011 muerto000000000100 muerto000000000122 ffff0000e232a7c9 sin procesar: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 página volcada porque: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/swap_state.c:184! Error interno: Ups - BUG: 00000000f2000800 [#1] Módulos SMP vinculados: CPU: 0 PID: 60 Comm: kswapd0 No contaminado 6.6.0-gcb097e7de84e #3 Nombre del hardware: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9: dfff800000000000 x8: 00009fffc9274686 x7: ffff0001b6c5cbd3 x6: 000000000000001 x5: ffff0000c25896c0 x4: 0000000000000000 x3: 00000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Rastreo de llamadas: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20 Puedo reproducir este problema con los siguientes pasos: 1) Cuando una página de caché de intercambio sucia es aislada por el proceso de recuperación y la página no está bloqueada, se inyecta un fallo de memoria para la página. me_swapcache_dirty() borra el indicador de actualización e intenta eliminarla de la unidad de recuperación (LRU), pero falla. El proceso de recuperación devolverá la página contaminada a la LRU. 2) El proceso que asigna la página contaminada sale, la página se elimina, la página nunca se liberará y permanecerá en la LRU para siempre. 3) Si activamos una recuperación de nuevo e intentamos recuperar la página, add_to_swap() activará VM_BUG_ON_FOLIO debido a que el indicador de actualización está borrado. Para solucionarlo, omita la página contaminada en la lista de recuperación (shrink_folio_list()). Además, es posible que el folio hwpoison aún no esté desasignado por hwpoison_user_mappings(), desasignelo en shrink_folio_list(), de lo contrario el folio no podrá ser desasignado por hwpoison_user_mappings() ya que el folio no está en la lista lru.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: scmi: Se corrige la corrección de null-ptr-deref en scmi_cpufreq_get_rate(). cpufreq_cpu_get_raw() puede devolver NULL cuando la CPU de destino no está presente en la máscara policy->cpus. scmi_cpufreq_get_rate() no comprueba este caso, lo que resulta en una desreferencia de puntero NULL. Añadir la comprobación de NULL después de cpufreq_cpu_get_raw() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: se corrige el acceso fuera de los límites en nvmet_enable_port Al intentar habilitar un puerto que aún no tiene transporte configurado, nvmet_enable_port() usa NVMF_TRTYPE_MAX (255) para consultar la matriz de transportes, lo que provoca un acceso fuera de los límites: [ 106.058694] ERROR: KASAN: global fuera de los límites en nvmet_enable_port+0x42/0x1da [ 106.058719] Lectura de tamaño 8 en la dirección ffffffff89dafa58 por la tarea ln/632 [...] [ 106.076026] nvmet: no se admite el tipo de transporte 255 Desde la confirmación 200adac75888, NVMF_TRTYPE_MAX es el estado predeterminado según la configuración de nvmet_ports_make(). Evite esto verificando NVMF_TRTYPE_MAX antes de continuar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la desreferencia del puntero NULL en tipc_mon_reinit_self() syzbot informó: tipc: Número de nodo establecido en 1055423674 Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 No contaminado 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Nombre del hardware: QEMU PC estándar (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: eventos tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [en línea] subproceso_de_trabajo+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_de_bifurcación+0x45/0x80 arch/x86/kernel/process.c:153 ret_de_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 00000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Hay una condición de ejecución entre la cola de trabajo creada al habilitar el portador y otro hilo creado al deshabilitar el portador justo después de eso, como se muestra a continuación: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: hfsc: Se corrige también un posible UAF en hfsc_dequeue(). Al igual que en el parche anterior, también debemos proteger hfsc_dequeue(). Sin embargo, para este caso, no contamos con un reproductor fiable.