Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> ubifs: Se corrige interbloqueo en concurrencia de un renombrado con whiteout simultáneo a la escritura del inodo.<br /> <br /> Tareas colgadas:<br /> [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132<br /> [ 77.028820] Call Trace:<br /> [ 77.029027] schedule+0x8c/0x1b0<br /> [ 77.029067] mutex_lock+0x50/0x60<br /> [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs]<br /> [ 77.029117] __writeback_single_inode+0x43c/0x570<br /> [ 77.029128] writeback_sb_inodes+0x259/0x740<br /> [ 77.029148] wb_writeback+0x107/0x4d0<br /> [ 77.029163] wb_workfn+0x162/0x7b0<br /> <br /> [ 92.390442] task:aa state:D stack: 0 pid: 1506<br /> [ 92.390448] Call Trace:<br /> [ 92.390458] schedule+0x8c/0x1b0<br /> [ 92.390461] wb_wait_for_completion+0x82/0xd0<br /> [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110<br /> [ 92.390472] writeback_inodes_sb_nr+0x14/0x20<br /> [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs]<br /> [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs]<br /> [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs]<br /> [ 92.390571] vfs_rename+0xdb2/0x1170<br /> [ 92.390580] do_renameat2+0x554/0x770<br /> <br /> , ocasionado por procesos simultáneos de renombrado con whiteout y escritura del inodo:<br /> rename_whiteout(Thread 1) wb_workfn(Thread2)<br /> ubifs_rename<br /> do_rename<br /> lock_4_inodes (Hold ui_mutex)<br /> ubifs_budget_space<br /> make_free_space<br /> shrink_liability<br /> __writeback_inodes_sb_nr<br /> bdi_split_work_to_wbs (Queue new wb work)<br /> wb_do_writeback(wb work)<br /> __writeback_single_inode<br /> ubifs_write_inode<br /> LOCK(ui_mutex)<br /> ?<br /> wb_wait_for_completion (Wait wb work) &amp;lt;-- ¡interbloqueo!<br /> <br /> Caso de prueba:<br /> 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT)<br /> 2. Consumir todo el espacio antes de que kernel(mdelay) planifique el whiteout<br /> <br /> Arreglado calculando el espacio de whiteout antes de bloquear los inodos de ubifs.<br /> <br /> También soluciona etiqueta la etiqueta goto errónea &amp;#39;out_release&amp;#39; en el flujo de errores<br /> de la planificación del whiteout (al menos debería recuperar el directorio i_size y desbloquear 4 inodos de ubifs).<br />

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: rename_whiteout: Se corrige la doble liberación para whiteout_ui-&amp;gt;data &amp;#39;whiteout_ui-&amp;gt;data&amp;#39; se liberará dos veces si el presupuesto de espacio falla para la operación de cambio de nombre de whiteout como el siguiente proceso: rename_whiteout dev = kmalloc whiteout_ui-&amp;gt;data = dev kfree(whiteout_ui-&amp;gt;data) // Libera la primera vez iput(whiteout) ubifs_free_inode kfree(ui-&amp;gt;data) // ¡Doble liberación! KASAN informa: ==================================================================== ERROR: KASAN: liberación doble o liberación no válida en ubifs_free_inode+0x4f/0x70 Seguimiento de llamadas: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Asignado por la tarea 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Liberado por la tarea 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 La dirección con errores pertenece al objeto en ffff88810238bed8 que pertenece al caché kmalloc-8 de tamaño 8 ===================================================================== Deje que ubifs_free_inode() libere &amp;#39;whiteout_ui-&amp;gt;data&amp;#39;. Por cierto, elimine la asignación no utilizada &amp;#39;whiteout_ui-&amp;gt;data_len = 0&amp;#39;, el proceso &amp;#39;ubifs_evict_inode() -&amp;gt; ubifs_jnl_delete_inode() -&amp;gt; ubifs_jnl_write_inode()&amp;#39; no lo necesita (porque &amp;#39;inc_nlink(whiteout)&amp;#39; no será ejecutado por &amp;#39;goto out_release&amp;#39;, y el nlink del inodo whiteout es 0).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/mmu: Se eliminan _todos_ las raíces al anular la asignación del rango gfn en TDP MMU Se eliminan las raíces válidas e inválidas al hacer zapping/anular la asignación de un rango gfn, ya que KVM debe asegurarse de que no contiene referencias a la página liberada después de regresar de la operación de anulación de la asignación. En particular, TDP MMU no elimina las raíces inválidas en las devoluciones de llamadas mmu_notifier. Esto conduce a problemas de use-after-free y otros problemas si mmu_notifier se ejecuta hasta el final mientras que un zapper de raíz inválida cede, ya que KVM no cumple con el requisito de que no debe haber _ninguna_ referencia a la página después de que mmu_notifier regrese. El error se reproduce más fácilmente pirateando KVM para provocar una colisión entre set_nx_huge_pages() y kvm_mmu_notifier_release(), pero el error también existe entre kvm_mmu_notifier_invalidate_range_start() y las actualizaciones de memslot. Invalidar una raíz garantiza que el invitado no pueda acceder a las páginas, y KVM no leerá ni escribirá datos de página por sí mismo, pero KVM activará, por ejemplo, kvm_set_pfn_dirty() al hacer zapping de SPTE, y por lo tanto, completar un zapping de una raíz no válida _después_ de que mmu_notifier regrese es fatal. ADVERTENCIA: CPU: 24 PID: 1496 en arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Rastreo de llamadas: kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_raíces_invalidadas+0x50/0x90 [kvm] kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm] set_nx_huge_pages+0xb4/0x190 [kvm] param_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1cc/0x270 ksys_write+0x5f/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/kasan: Se solucionó que la región temprana no se actualizara correctamente La tabla de páginas de shadow no se actualiza cuando PTE_RPN_SHIFT es 24 y PAGE_SHIFT es 12. No solo causa falsos positivos sino también falsos negativos como se muestra en el siguiente texto. Arréglelo trayendo la lógica de kasan_early_shadow_page_entry aquí. 1. Falso positivo: ==================================================================== ERROR: KASAN: vmalloc fuera de los límites en pcpu_alloc+0x508/0xa50 Escritura de tamaño 16 en la dirección f57f3be0 por la tarea swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.15.0-12267-gdebe436e77c7 #1 Seguimiento de llamadas: [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (no confiable) [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300 [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200 [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0 [c80d1cc0] [c03018a4] memset+0x34/0x90 [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50 [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384 [c80d1ef0] [c0004b14] kernel_init+0x24/0x170 [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64 Estado de la memoria alrededor de la dirección con errores: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 &amp;gt;f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ===================================================================== 2. Falso negativo (con pruebas KASAN): ==================================================================== Antes de la corrección: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATIVA FALLÓ en lib/test_kasan.c:1039 Se esperaba una falla de KASAN en "((volatile char *)area)[3100]", pero no ocurrió ninguna no ok 46 - vmalloc_oob no ok 1 - kasan ======================================================================== Después de la corrección: ok 1 - kasan

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: cirrusfb: comprobar pixclock para evitar la división por cero Realice una comprobación de la depuración del valor de pixclock para evitar la división por cero. Si el valor de pixclock es cero, el controlador cirrusfb redondeará el valor de pixclock para obtener la frecuencia derivada lo más cercana posible a maxclock. Syzkaller informó un error de división en cirrusfb_check_pixclock. Error de división: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test No contaminado 5.15.0-rc6 #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Seguimiento de llamadas: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: nvidiafb: Use strscpy() para evitar el desbordamiento del búfer Coverity se queja de un posible desbordamiento del búfer. Sin embargo, dado el alcance &amp;#39;estático&amp;#39; de nvidia_setup_i2c_bus(), parece que eso no puede suceder después de examinar los sitios de llamada. CID 19036 (#1 de 1): Copiar en un búfer de tamaño fijo (STRING_OVERFLOW) 1. fixed_size_dest: Puede desbordar la cadena de tamaño fijo de 48 caracteres chan-&amp;gt;adapter.name copiando name sin verificar la longitud. 2. parameter_as_source: Nota: Este defecto tiene un riesgo elevado porque el argumento source es un parámetro de la función actual. 89 strcpy(chan-&amp;gt;adapter.name, name); Corrija esta advertencia usando strscpy() que silenciará la advertencia y evitará futuros desbordamientos del búfer si los nombres utilizados para identificar el canal se vuelven mucho más largos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: davinci: da850-evm: Evitar la desreferencia de puntero NULL Con versiones más nuevas de GCC, hay un pánico en da850_evm_config_emac() al iniciar multi_v5_defconfig en QEMU bajo la máquina palmetto-bmc: No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Error interno: Oops: 5 [#1] PREEMPT Módulos ARM vinculados: CPU: 0 PID: 1 Comm: swapper No contaminado 5.15.0 #1 Nombre del hardware: Sistema genérico basado en DT La PC está en da850_evm_config_emac+0x1c/0x120 LR está en El puntero emac_pdata en soc_info es NULL porque davinci_soc_info solo se completa en máquinas davinci, pero se llama a da850_evm_config_emac() en todas las máquinas a través de device_initcall(). Mueva la asignación rmii_en debajo de la verificación de la máquina para que solo se desreferencia cuando se ejecuta en un SoC compatible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/set_memory: Evitar recursión de spinlock en change_page_attr() La confirmación 1f9ad21c3b38 ("powerpc/mm: Implementar rutinas set_memory()") incluyó un spin_lock() en change_page_attr() para realizar de forma segura las operaciones de tres pasos. Pero luego, la confirmación 9f7853d7609d ("powerpc/mm: Arreglar set_memory_*() contra accesos concurrentes") lo modificó para usar pte_update() y realizar la operación de forma segura contra accesos concurrentes. Mientras tanto, Maxime informó de cierta recursión de spinlock. [ 15.351649] ERROR: recursión de spinlock en CPU#0, kworker/0:2/217 [ 15.357540] bloqueo: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0 [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 No contaminado 5.15.0+ #523 [ 15.373350] Cola de trabajo: events do_free_init [ 15.377615] Call Trace: [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable) [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4 [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0 [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8 [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94 [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134 [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8 [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8 [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94 [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8 [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8 [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210 [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c Elimina la secuencia de lectura/modificación/escritura para hacer que la operación sea atómica y elimina el spin_lock() en change_page_attr(). Para hacer la operación de forma atómica, ya no podemos usar ayudantes de modificación de pte. Debido a que todas las plataformas tienen diferentes combinaciones de bits, no es fácil usar esos bits directamente. Pero todas tienen el conjunto de indicadores _PAGE_KERNEL_{RO/ROX/RW/RWX}. Todo lo que necesitamos es comparar dos conjuntos para saber qué bits están configurados o borrados. Por ejemplo, al comparar _PAGE_KERNEL_ROX y _PAGE_KERNEL_RO sabes qué bit se borra y qué bit se configura al cambiar el permiso de ejecución.

Existe un esquema de autorización roto donde cualquier usuario autenticado podría descargar archivos de configuración y scripts de IOA si se conoce la URL.

Existe una vulnerabilidad de divulgación de credenciales donde un administrador podría extraer las credenciales de la cuenta SMTP almacenadas debido a la falta de cifrado.

HCL MyCloud se ve afectado por un control de acceso inadecuado, una vulnerabilidad de escalada de privilegios no autenticados que puede provocar la divulgación de información y posibles ataques de Server-Side Request Forgery (SSRF) y de denegación de servicio (DOS) por parte de usuarios no autenticados.

Seacms &amp;lt;=13.3 es vulnerable a la inyección SQL en admin_paylog.php.