Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/ib_srp: corrige un punto muerto Elimine la llamada Flush_workqueue(system_long_wq) ya que vaciar system_long_wq es propenso a interbloqueo y esa llamada es redundante con un cancel_work_sync() anterior.

El complemento AcyMailing – An Ultimate Newsletter Plugin and Marketing Automation Solution para WordPress es vulnerable a cargas de archivos arbitrarias debido a la falta de validación del tipo de archivo en la función acym_extractArchive en todas las versiones hasta la 9.7.2 incluida. Esto hace posible que atacantes autenticados, con acceso de nivel de suscriptor y superior, carguen archivos arbitrarios en el servidor del sitio afectado, lo que puede hacer posible la ejecución remota de código.

El complemento Themify Builder para WordPress es vulnerable a la duplicación de publicaciones no autorizada debido a la falta de controles en la función duplicate_page_ajaxify en todas las versiones hasta la 7.6.1 incluida. Esto hace posible que los atacantes autenticados, con acceso de nivel Colaborador y superior, dupliquen y vean publicaciones privadas o borradores creados por otros usuarios a los que de otro modo no deberían tener acceso.

Dell Power Manager (DPM), versiones 3.15.0 y anteriores, contiene una vulnerabilidad de asignación de privilegios incorrecta. Un atacante con pocos privilegios y acceso local podría explotar esta vulnerabilidad, lo que provocaría la ejecución de código y la elevación de privilegios.

Los complementos The Plus Addons for Elementor – Elementor Addons, Page Templates, Widgets, Mega Menu, WooCommerce para WordPress son vulnerables a Cross-Site Scripting Almacenado a través del parámetro carousel_direction del widget de testimonios en todas las versiones hasta la 5.6.2 incluida, debido a una desinfección insuficiente de las entradas y a que la salida se escape en los atributos proporcionados por el usuario. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/fair: Solucionar falla en reweight_entity Syzbot encontró un GPF en reweight_entity. Esto se ha dividido en dos para el commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() accede a un sched_task_group no válido") Hay una ejecución entre sched_post_fork() y setpriority(PRIO_PGRP) dentro de un grupo de subprocesos que provoca un null-ptr-deref en reweight_entity () en el SFC. El escenario es que el proceso principal genera una cantidad de subprocesos nuevos, que luego llaman a setpriority(PRIO_PGRP, 0, -20), esperan y salen. Para cada uno de los nuevos subprocesos, se invoca copy_process(), lo que agrega la nueva task_struct y llama a sched_post_fork() para ello. En el escenario anterior existe la posibilidad de que se llame a setpriority(PRIO_PGRP) y set_one_prio() para un subproceso en el grupo que acaba de crear copy_process(), y para el cual sched_post_fork() aún no se ha ejecutado. Esto desencadenará una desreferencia del puntero nulo en reweight_entity(), ya que intentará acceder al puntero de la cola de ejecución, que no se ha configurado. Antes del cambio mencionado, el puntero cfs_rq para la tarea se configuró en sched_fork(), que se llama mucho antes en copy_process(), antes de que la nueva tarea se agregue al thread_group. Ahora se hace en sched_post_fork(), que se llama después de eso. Para solucionar el problema, elimine el parámetro update_load de la función update_load param() y llame a reweight_task() solo si el indicador de tarea no tiene establecido el indicador TASK_NEW.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige los errores causados por el rastreador de latencia irqsoff trace_hardirqs_{on,off}() requiere que la persona que llama configure el puntero del marco correctamente. Esto se debe a que estas dos funciones utilizan la macro 'CALLER_ADDR1' (también conocida como __builtin_return_address(1)) para adquirir información de la persona que llama. Si $fp se usa para otro propósito, el código generado en esta macro (como se muestra a continuación) podría provocar una falla de acceso a la memoria. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- error de paginación aquí El mensaje de ups durante el arranque si se compila con el rastreador 'irqoff' habilitado: [ 0.039615][T0] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000f8 [0.041925][T0] Ups [#1] [0.042063][T0] Módulos vinculados en: [0.042864][T0] CPU: 0 PID: 0 Comm : swapper/0 No contaminado 5.17.0-rc1-00233-g9a20c48d1ed2 #29 [ 0.043568][ T0] Nombre de hardware: riscv-virtio,qemu (DT) [ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2 [ 0.044601] [T0] ra: restaurar_all+0x12/0x6e [0.044721][T0] epc: ffffffff80126a5c ra: ffffffff80003b94 sp: ffffffff81403db0 [0.044801][T0] gp: ffffffff8163acd8 tp: ffffffff81414880 t0: 0000000000000020 [0.044882][T0] t1: 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0 [ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100 [ 0.045046][ T0] a2: 0000000000000000 a3: 0000000000000000 a4: 0000000000000000 [0.045124][T0] a5: 00000000000000000 a6: 0000000000000000 a7: 000000 0054494d45 [ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50 [ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00800120e8 [ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 00000000000000000 [ 0.045474][ T0 ] s11: 0000000000000000 t3: 7ffffffffffffff t4: 0000000000000000 [0.045548][T0] t5: 0000000000000000 t6: ffffffff814aa368 [0.045620][T0] 0000000200000100 badaddr: 00000000000000f8 causa: 000000000000000d [ 0.046402][ T0] [] restaurar_todo+ 0x12/0x6e Esto porque el $fp(aka. $s0) el registro no se utiliza como puntero de marco en el código de entrada del ensamblado. resume_kernel: reg_l s0, task_ti_preempt_count (tp) bnez s0, restaure_all reg_l s0, task_ti_flags (tp) andi s0, s0, _tif_need_resched beqz s0, restaure_all call preempt_schedul S_ { on,off}() para que puedan ser llamados de forma segura mediante un código de entrada de bajo nivel.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: evita copiar un segmento lzo comprimido demasiado grande. La longitud comprimida puede corromperse y ser mucho mayor que la memoria que hemos asignado para el búfer. Esto hará que memcpy en copy_compressed_segment escriba fuera de la memoria asignada. Esto principalmente da como resultado una llamada al sistema de lectura bloqueada, pero a veces, cuando se usa el envío btrfs, se puede obtener el kernel #GP: falla de protección general, probablemente para la dirección no canónica 0x841551d5c1000: 0000 [#1] Kernel PREEMPT SMP NOPTI: CPU: 17 PID: 264 Comm: kworker /u256:7 Contaminado: P OE 5.17.0-rc2-1 #12 kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs] kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs /btrfs/lzo.c:322 fs/btrfs/lzo.c:394) Código btrfs que comienza con la instrucción errónea ========================== ================== 0:* 48 8b 06 mov (%rsi),%rax <-- instrucción de captura 3: 48 8d 79 08 lea 0x8(%rcx), %rdi 7: 48 83 e7 f8 y $0xffffffffffffffff8,%rdi b: 48 89 01 mov %rax,(%rcx) e: 44 89 f0 mov %r14d,%eax 11: 48 8b 54 06 f8 mov -0x8(% rsi,%rax,1),%rdx kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212 kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8 kernel: RDX: 0000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000 kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000 kernel: R13: 0000000000000008 R14: 00000000000 01000 R15: 000841551d5c1000 kernel: FS: 0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:00000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0 kernel: Seguimiento de llamadas: kernel: kernel: end_compressed_bio_read (fs/btrfs/compression.c: 104 fs/btrfs/compression.c:1363 fs /btrfs/compression.c:323) kernel btrfs: end_workqueue_fn (fs/btrfs/disk-io.c:1923) kernel btrfs: btrfs_work_helper (fs/btrfs/async-thread.c:326) kernel btrfs: Process_one_work (./ arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312) kernel: trabajador_thread (. /include/linux/list.h:292 kernel/workqueue.c:2455) kernel:? Process_one_work (kernel/workqueue.c:2397) kernel: kthread (kernel/kthread.c:377) kernel:? kthread_complete_and_exit (kernel/kthread.c:332) kernel: ret_from_fork (arch/x86/entry/entry_64.S:301) kernel:

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: térmica: int340x: corrige la pérdida de memoria en int3400_notify() Es fácil solucionar las siguientes pérdidas de memoria en mi plataforma TigerLake: objeto sin referencia 0xffff927c8b91dbc0 (tamaño 32): comm "kworker/0 :2", pid 112, santiamén 4294893323 (edad 83.604s) volcado hexadecimal (primeros 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. seguimiento: [] __kmalloc_track_caller+0x2fe/0x4a0 [] kvasprintf+0x65/0xd0 [] kasprintf+0x4e/0x70 [] notificar+0x82/0x120 [int3400_thermal] [] acpi_ev_notify_dispatch+0x54/0x71 [] acpi_os_execute_deferred+0x17/0x30 [] Process_one_work+0x21a/0x3f0 [] trabajador_thread+0x4a/0x3b0 ffffffff9c2cb4dd>] kthread+0xfd/0x130 [] ret_from_fork+0x1f/0x30 Solucionarlo llamando a kfree() en consecuencia.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: no cambie route.addr.src_addr fuera de las comprobaciones de estado. Si el estado no está inactivo, resolve_prepare_src() debería fallar inmediatamente y no debería ocurrir ningún cambio en el estado global. Sin embargo, sobrescribe incondicionalmente src_addr al intentar crear una dirección temporal. Por ejemplo, si el estado ya es RDMA_CM_LISTEN, esto dañará src_addr y provocará la prueba en cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) Lo que se manifestaría como este rastro de syzkaller: ERROR : KASAN: use-after-free en __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Lectura de tamaño 8 en addr ffff8881546491e0 por tarea syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 No contaminado 5.12.0-rc8-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack+0x141/0x1d7 lib /dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [en línea] kasan_report.cold+0x7c/0xd8 mm/kasan/ report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [en línea] list_add_tail include/linux/list.h:100 [en línea] cma_listen_on_all drivers/infiniband/core/ cma.c:2557 [en línea] rdma_listen+0x787/0xe00 controladores/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 controladores/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 controladores/infiniband/core /ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Entry_SYSCALL_64_after_hwframe+0x44/ 0xae Esto indica que un rdma_id_private fue destruido sin realizar cma_cancel_listens(). En lugar de intentar reutilizar la memoria src_addr para crear indirectamente cualquier dirección derivada del dst, cree una explícitamente en la pila y vincúlela como lo haría cualquier otro flujo normal. rdma_bind_addr() lo copiará sobre src_addr una vez que sepa que el estado es válido. Esto es similar al commit bc0bdc5afaa7 ("RDMA/cma: No cambiar route.addr.src_addr.ss_family")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: elimina la advertencia en el commit de transacción cuando se usa fluoncommit Cuando se usa la opción de montaje fluoncommit, durante casi cada commit de transacción activamos una advertencia de __writeback_inodes_sb_nr(): $ cat fs/fs -writeback.c: (...) vacío estático __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (... ) La traza producida en dmesg se parece a la siguiente: [947.473890] ADVERTENCIA: CPU: 5 PID: 930 en fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Módulos vinculados en: nfsd nls_cp437 cifs asn1_decoder s_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti No contaminado 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: __writeback_inodes_sb_nr +0x7e/0xb3 [947.502097] Código: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 X: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP : ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 00000000000000002 R11: 0000000000000001 R12: ffff88810096 3488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40 000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e 0 [947.571072] Seguimiento de llamadas: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? Schedule_timeout+0x8a/0xdd [947.582716] transacción_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]--- Esto se debe a que comenzamos a usar writeback_inodes_sb() para vaciar delalloc cuando cometer una transacción (cuando se usa -o fluoncommit), para evitar interbloqueos con las operaciones de congelación del sistema de archivos. Este cambio se realizó mediante el commit ce8ea7cc6eb313 ("btrfs: no llame a btrfs_start_delalloc_roots en flowoncommit"). Después de ese cambio, comenzamos a producir esa advertencia y, de vez en cuando, un usuario informa esto ya que la advertencia ocurre con demasiada frecuencia, envía spam a dmesg/syslog y el usuario no está seguro de si esto refleja algún problema que pueda comprometer la confiabilidad del sistema de archivos. No podemos simplemente bloquear el semáforo sb->s_umount antes de llamar a writeback_inodes_sb(), porque eso al menos bloquearía el sistema de archivos, ya que en fs/super.c:freeze_super() se llama a sync_filesystem() mientras mantenemos ese semáforo en modo de escritura, y eso puede desencadenar un commit de transacción, lo que resulta en un punto muerto. También desencadenaría el mismo tipo de punto muerto en la ruta de desmontaje. Posiblemente, también podría introducir algunas otras dependencias de bloqueo que lockdep informaría. Para solucionar este problema, llame a try_to_writeback_inodes_sb() en lugar de writeback_inodes_sb(), porque intentará leer el bloqueo sb->s_umount y luego solo llamará a writeback_inodes_sb() si pudo bloquearlo. Esto está bien porque los casos en los que no puede leer el bloqueo sb->s_umount son durante un desmontaje del sistema de archivos o durante una congelación del sistema de archivos; en esos casos, sb->s_umount está bloqueado contra escritura y se llama a sync_filesystem(), que llama a writeback_inodes_sb() . En otras palabras, en todos los casos en los que no podemos adoptar un bloqueo de lectura en sb->s_umount, la reescritura ya se está activando en otro lugar. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: elemento de trabajo de reinicio gratuito al vaciar Se corrige una pequeña pérdida de memoria al vaciar la cola de trabajo de reinicio.