Vulnerabilidades

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: ath5k: corrección de OOB en ath5k_eeprom_read_pcal_info_5111 El error se encontró durante el fuzzing. Stacktrace lo ubica en ath5k_eeprom_convert_pcal_info_5111. Cuando no se selecciona ninguna de las curvas en el bucle, idx puede llegar hasta AR5K_EEPROM_N_PD_CURVES. La línea hace que pd esté fuera de los límites. pd = &amp;amp;chinfo[pier].pd_curves[idx]; Hay muchas escrituras OOB que usan pd más adelante en el código. Así que agregué una verificación de cordura para idx. No se necesitan verificaciones para otros bucles que involucran AR5K_EEPROM_N_PD_CURVES ya que el índice del bucle no se usa fuera de los bucles. El parche NO se prueba con un dispositivo real. El siguiente es el informe de fuzzing ERROR: KASAN: slab-out-of-limits en ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Escritura de tamaño 1 en la dirección ffff8880174a4d60 por la tarea modprobe/214 CPU: 0 PID: 214 Comm: modprobe No contaminado 5.6.0 #1 Seguimiento de llamadas: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 realmente_probe+0x209/0x5d0

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&amp;#39;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: 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: 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.

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.

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_type_news.php.

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