Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Corrección para agregar refcount una vez que la página se establece como privada MM definió la regla [1] muy claramente que una vez que la página se establece con el indicador PG_private, debemos incrementar el refcount en esa página, también los flujos principales como pageout(), migrants_page() asumirán que hay un recuento de referencia de página adicional si page_has_private() devuelve verdadero. De lo contrario, podemos obtener un ERROR en la migración de la página: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) página volcada porque: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cortar aquí ]------------ ¡ERROR del kernel en include/linux/page_ref.h:184! código de operación no válido: 0000 [#1] CPU SMP: 3 PID: 38 Comm: kcompactd0 No contaminado 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Rastreo de llamadas: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrants_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Antes de tiempo, deberíamos aclarar un concepto, qué significa refcount en la página obtenida de grab_cache_page_write_begin(). Hay 2 situaciones: Situación 1: refcount es 3, la página es creada por __page_cache_alloc. TYPE_A - el proceso de escritura está usando esta página TYPE_B - la página es asignada a un cierto mapeo llamando a __add_to_page_cache_locked() TYPE_C - la página es agregada a la lista pagevec correspondiente a la CPU actual llamando a lru_cache_add() Situación 2: refcount es 2, la página es obtenida del árbol del mapeo TYPE_B - la página ha sido asignada a un cierto mapeo TYPE_A - el proceso de escritura está usando esta página (llamando a page_cache_get_speculative()) El sistema de archivos libera un refcount llamando a put_page() en xxx_write_end(), el refcount liberado corresponde a TYPE_A (la tarea de escritura lo está usando). Si hay algún proceso usando una página, el proceso de migración de página omitirá la página al juzgar si expected_page_refs() es igual a page refcount. El ERROR es causado por el siguiente proceso: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // coloca la página en el pagevec de la CPU 0 (refcnf = 3, para el proceso de creación de la página) ubifs_write_end SetPagePrivate(page_a) // ¡no aumenta el número de páginas! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS no aumenta el recuento de referencias de la página después de configurar el indicador privado, lo que hace que la tarea de migración de la página crea que ningún otro proceso utiliza la página, por lo que se migra la página. Esto provoca un acceso simultáneo al recuento de referencias de la página entre put_page() llamado por otro proceso (por ejemplo, el proceso de lectura llama a lru_cache_add) y page_ref_unfreeze() llamado por mi ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Se corrige la lectura fuera de los límites en la función ubifs_wbuf_write_nolock() ubifs_wbuf_write_nolock() puede acceder a buf fuera de los límites en el siguiente proceso: ubifs_wbuf_write_nolock(): classified_len = ALIGN(len, 8); // Supongamos que len = 4089, classified_len = 4096 if (aligned_len <= wbuf->avail) ... // No satisface if (wbuf->used) { ubifs_leb_write() // Complete algunos datos en avail wbuf len -= wbuf->avail; // len aún no está alineado a 8 bytes classified_len -= wbuf->avail; } n = classified_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + escrito, wbuf->offs, n); // n > len, lectura fuera de los límites menor a 8(n-len) bytes }, lo cual puede ser detectado por KASAN: =========================================================== ERROR: KASAN: slab fuera de los límites en ecc_sw_hamming_calculate+0x1dc/0x7d0 Lectura de tamaño 4 en la dirección ffff888105594ff8 por la tarea kworker/u8:4/128 Cola de trabajo: escritura diferida wb_workfn (flush-ubifs_0_0) Rastreo de llamadas: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 La función ubifs_wbuf_write_nolock() acepta que el parámetro 'len' no esté alineado con 8 bytes, 'len' representa la longitud verdadera de buf (que está asignada en 'ubifs_jnl_xxx', p. ej. ubifs_jnl_write_inode), por lo que ubifs_wbuf_write_nolock() debe manejar la longitud leída de 'buf' con cuidado para escribir leb de forma segura. Obtenga un reproductor en [Enlace].

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.