Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, thp: rescatar temprano en el colapso_archivo para la página de reescritura. Actualmente, colapso_archivo no verifica explícitamente PG_writeback; en su lugar, page_has_private y try_to_release_page se utilizan para filtrar las páginas de reescritura. Esto no funciona para xfs con un tamaño de bloque igual o mayor que el tamaño de página, porque en tal caso xfs no tiene página->privada. Esto hace que colapso_file salga anticipadamente de la página de reescritura. De lo contrario, xfs end_page_writeback entrará en pánico de la siguiente manera. página:fffffe00201bcc80 refcount:0 mapcount:0 mapeo:ffff0003f88c86a8 índice:0x0 pfn:0x84ef32 aops:xfs_address_space_operaciones [xfs] ino:30000b7 nombre dentry:"libtest.so" banderas: 0x57fffe0000008027(bloqueado|referenciado| actualización|activo|reescritura) sin formato : 57fffe0000008027 ffff80001b48bc28 ffff80001b48bc28 ffff0003f88c86a8 crudo: 0000000000000000 00000000000000000 00000000ffffffff página volcada porque: VM_BUG_ON_PAGE(((unsigned int) page_ref_count(page) + 127u <= 127u)) page->mem_cgroup:ffff0000c3e9a000 ----------- -[ cortar aquí ]------------ ¡ERROR del kernel en include/linux/mm.h:1212! Error interno: Ups - ERROR: 0 [#1] Módulos SMP vinculados en: ERROR: Estado de página incorrecto en el proceso khugepaged pfn:84ef32 xfs(E) page:fffffe00201bcc80 refcount:0 mapcount:0 mapeo:0 index:0x0 pfn:0x84ef32 libcrc32c(E) rfkill(E) aes_ce_blk(E) crypto_simd(E) ... CPU: 25 PID: 0 Comm: swapper/25 Kdump: cargado Contaminado: ... pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) Seguimiento de llamadas: end_page_writeback+0x1c0/0x214 iomap_finish_page_writeback+0x13c/0x204 iomap_finish_ioend+0xe8/0x19c iomap_writepage_end_bio+0x38/0x50 bio_endio+0x168/0x1ec blk_update_request+0x278/0x 3f0 blk_mq_end_request+0x34/0x15c virtblk_request_done+0x38/0x74 [virtio_blk ] blk_done_softirq+0xc4/0x110 __do_softirq+0x128/0x38c __irq_exit_rcu+0x118/0x150 irq_exit+0x1c/0x30 __handle_domain_irq+0x8c/0xf0 gic_handle_irq+0x84/0x108 xcc/0x180 arch_cpu_idle+0x18/0x40 default_idle_call+0x4c/0x1a0 cpuidle_idle_call+0x168/ 0x1e0 do_idle+0xb4/0x104 cpu_startup_entry+0x30/0x9c second_start_kernel+0x104/0x180 Código: d4210000 b0006161 910c8021 94013f4d (d4210000) ---[ end trace 4a88c6a074082f 8c ]--- Pánico en el kernel - no se sincroniza: Ups - ERROR: excepción fatal en la interrupción

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la ejecución entre fragmentos de búsqueda y libera journal_head de buffer_head Se encontró una ejecución entre ocfs2_test_bg_bit_allocatable() y jbd2_journal_put_journal_head() que resultó en el siguiente vmcore. PID: 106879 TAREA: ffff880244ba9c00 CPU: 2 COMANDO: "loop3" Rastreo de llamadas: pánico oops_end no_context __bad_area_nosemaphore bad_area_nosemaphore __do_page_fault do_page_fault page_fault [excepción RIP: ocfs2_block_group_find_clear_bits+316] 2_block_group_find_clear_bits [ocfs2] ocfs2_cluster_group_search [ocfs2] ocfs2_search_chain [ocfs2] ocfs2_claim_suballoc_bits [ocfs2] __ocfs2_claim_clusters [ocfs2] ocfs2_claim_clusters [ocfs2] ocfs2_local_alloc_slide_window [ocfs2] ocfs2_reserve_local_alloc_bits [ocfs2] ocfs2_reserve_clusters_with_limit [ocfs2] ocfs2_reserve_clusters [ocfs2] ocfs2_lock_refcount_allocators [ocfs2] 2_make_clusters_writable [ocfs2] ocfs2_replace_cow [ocfs2] ocfs2_refcount_cow [ocfs2] ocfs2_file_write_iter [ocfs2] lo_rw_aio loop_queue_work kthread_worker_fn kthread ret_from_fork Cuando ocfs2_test_bg_bit_allocatable () llamado bh2jh(bg_bh), el bg_bh->b_private NULL como jbd2_journal_put_journal_head() corrió y liberó el encabezado del diario del encabezado del búfer. Era necesario bloquear el bit 'BH_JournalHead' para solucionar esta ejecución.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cfg80211: corrige el bloqueo de registros de administración. El bloqueo de registros de administración estaba roto, la lista estaba bloqueada para cada wdev, pero cfg80211_mgmt_registrations_update() la repitió sin mantener todos los spinlocks correctos, lo que provocó corrupción en la lista. En lugar de intentar solucionarlo con un bloqueo detallado, simplemente mueva el bloqueo a wiphy/rdev (aún necesitamos la lista en cada wdev), ya necesitamos mantener presionado el bloqueo wdev para cambiarlo, por lo que no hay contención en el bloqueo. En todo caso. Esto soluciona trivialmente el error ya que ya tenemos un bloqueo de wdev y ahora mantendremos el bloqueo que protege todas las listas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: verificación de cordura para maxpacket maxpacket de 0 no tiene sentido y falla ya que necesitamos dividirlo por él. Abandonar. V2: error tipográfico corregido en el registro y problemas de estilo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrige las llamadas invertidas de tls_err_abort() sk->sk_err parece esperar un valor positivo, una convención que ktls no siempre sigue y que conduce a daños en la memoria en otro código. Por ejemplo, [kworker] tls_encrypt_done(..., err=) tls_err_abort(.., err) sk->sk_err = err; [tarea] splice_from_pipe_feed ... tls_sw_do_sendpage if (sk->sk_err) { ret = -sk->sk_err; // ret es positivo splice_from_pipe_feed (continuación) ret = actor(...) // ret sigue siendo positivo y se interpreta como bytes // escritos, lo que resulta en un desbordamiento insuficiente de buf->len y // sd->len, lo que genera enormes buf->offset y bogus // direcciones calculadas en llamadas posteriores a actor(). Repare todas las llamadas tls_err_abort() para que pasen un código de error negativo de manera consistente y centralice el cambio de señal propenso a errores allí, lanzando una advertencia para detectar futuros usos indebidos y eliminación de líneas. la función por lo que realmente solo advierte una vez.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmem: corrige el desplazamiento fuera de los límites (UBSAN) con celdas de tamaño de bytes. Si una celda tiene 'nbits' iguales a un múltiplo de BITS_PER_BYTE, la lógica *p &= GENMASK( (celda->nbits%BITS_PER_BYTE) - 1, 0); se convertirá en un comportamiento indefinido porque el módulo de nbits BITS_PER_BYTE es 0, y restamos uno de eso, lo que genera un número grande que luego se desplaza más que el número de bits que caben en un largo sin signo. UBSAN informa este problema: UBSAN: desplazamiento fuera de los límites en drivers/nvmem/core.c:1386:8 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'largo sin firmar' CPU: 6 PID: 7 Comm: kworker /u16:0 Not tainted 5.15.0-rc3+ #9 Nombre del hardware: Google Lazor (rev3+) con KB Backlight (DT) Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack +0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 mem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 componente_bind_all+0xf0/0x264 msm_drm_bind +0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c componente_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 very_probe+0x110/0x304 _device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv +0x90/0xdc __device_attach+0xc8/0x174 dispositivo_inicial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 diferido_probe_work_func+0x7c/0xb8 proceso_one_work+0x128/0x21c proceso_scheduled_works+0x40/0x54 trabajador_hilo+0 x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Arreglar asegurándose de que haya partes que enmascarar.

El complemento ApplyOnline – Application Form Builder and Manager para WordPress es vulnerable al acceso no autorizado a los datos debido a una falta de verificación de capacidad en la acción aol_modal_box AJAX en todas las versiones hasta la 2.6 incluida. Esto hace posible que los atacantes autenticados, con acceso de suscriptor o superior, vean los envíos de aplicaciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm rq: no poner en cola la solicitud a blk-mq durante la suspensión de DM. DM utiliza la función de reposo/inquiesce de blk-mq para detener/iniciar la cola del asignador de dispositivos. Pero la inquietud de blk-mq puede provenir de eventos externos, como el cambio de ascensor, la actualización de nr_requests u otros, y la solicitud puede ocurrir durante la suspensión, así que simplemente solicite que blk-mq la vuelva a poner en cola. Soluciona un problema de pánico del kernel al ejecutar la actualización de nr_requests y la prueba de esfuerzo de suspensión/reanudación de dm-mpath.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mlx5: inicialice el xarray ODP al crear un ODP MR. Normalmente, el relleno con ceros ocultaría la inicialización faltante, pero un conjunto erróneo en desc_size en reg_create() provoca un bloqueo: ERROR : no se puede manejar el error de página para la dirección: 0000000800000000 PGD 0 P4D 0 Ups: 0000 [#1] SMP PTI CPU: 5 PID: 890 Comm: ib_write_bw Not tainted 5.15.0-rc4+ #47 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS REL-1.13.0-0-GF21B5A4AB02-PreBuilt e8 37 30 03 e1 48 8b 0c 24 eb a0 90 0f 1f 44 00 00 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 30 <48> 8b 2f 65 48 8b 04 25 28 00 0 00 48 89 44 24 28 31 c0 8b 87 c8 RSP: 0018:ffff88811afa3a60 EFLAGS: 00010286 RAX: 000000000000001c RBX: 0000000800000000 RCX: 0000000000000000 RDX: 00000000000 RSI: 0000000000000000 RDI: 0000000800000000 RBP: 0000000800000000 R08: 0000000000000000 R09: c0000000fffff7ff R10: 8f8 R11: ffff88811afa38f0 R12: fffffffa02c7ac0 R13: 00000000000000000000 R14: FFFF88811AFA3CD8 R15: FFFFF888810772200 FS: 00007F47B9080740 (0000) GS: FFFF88852CD40000 (0000) Knlgs: 00000000000000 C. : 0000000080050033 CR2: 0000000800000000 CR3: 000000010761E003 CR4: 0000000000370EA0 DR0: 000000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: mlx5_ib_free_odp_mr+0x95/0xc0 5_ib] mlx5_ib_dereg_mr+0x128/0x3b0 [mlx5_ib] ib_dereg_mr_user+0x45/0xb0 [ib_core] ? xas_load+0x8/0x80 destroy_hw_idr_uobject+0x1a/0x50 [ib_uverbs] uverbs_destroy_uobject+0x2f/0x150 [ib_uverbs] uobj_destroy+0x3c/0x70 [ib_uverbs] ib_uverbs_cmd_verbs+0x467/0xb00 [ib_uver bs] ? uverbs_finalize_object+0x60/0x60 [ib_uverbs]? ttwu_queue_wakelist+0xa9/0xe0 ? pty_write+0x85/0x90? file_tty_write.isra.33+0x214/0x330 ? Process_echoes+0x60/0x60 ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs] __x64_sys_ioctl+0x10d/0x8e0? vfs_write+0x17f/0x260 do_syscall_64+0x3c/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae Agregue la inicialización de xarray que falta y elimine el conjunto desc_size.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: batman-adv: corrección de manejo de errores Syzbot informó advertencia ODEBUG en batadv_nc_mesh_free(). El problema estaba en el manejo incorrecto de errores en batadv_mesh_init(). Antes de este parche, batadv_mesh_init() llamaba a batadv_mesh_free() en caso de que fallara alguna llamada a batadv_*_init(). Este enfoque puede funcionar bien cuando hay algún tipo de indicador que puede indicar qué partes de batadv están inicializadas; pero no hay ninguno. Todo lo escrito anteriormente conduce a la sanitización de campos no inicializados. Incluso si ocultamos la advertencia ODEBUG inicializando bat_priv->nc.work, syzbot pudo presionar GPF en batadv_nc_purge_paths(), porque el puntero hash todavía es NULL. [1] Para corregir estos errores podemos desenredar las llamadas batadv_*_init() una por una. Es un buen enfoque por 2 razones: 1) Corrige errores en la ruta de manejo de errores 2) Mejora el rendimiento, ya que no llamaremos a funciones batadv_*_free() innecesarias. Entonces, este parche hace que batadv_*_init() limpie toda la memoria asignada antes de regresar con un error de no llamada correspondiente a batadv_*_free() y códigos abiertos batadv_mesh_free() con el orden adecuado para evitar tocar campos no inicializados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regmap: corrige posible doble liberación en regcache_rbtree_exit() En regcache_rbtree_insert_to_block(), cuando la realloc 'presente' fallaba, el 'blk' que se supone debe asignarse a 'rbnode->block ' se liberará, por lo que 'rbnode->block' apunta a una memoria liberada, en la ruta de manejo de errores de regcache_rbtree_init(), 'rbnode->block' se liberará nuevamente en regcache_rbtree_exit(), KASAN informará la doble liberación de la siguiente manera : ERROR: KASAN: doble libre o no válido en kfree+0xce/0x390 Rastreo de llamadas: slab_free_freelist_hook+0x10d/0x240 kfree+0xce/0x390 regcache_rbtree_exit+0x15d/0x1a0 regcache_rbtree_init+0x224/0x2c0 regcache_init+0x88d/ 0x1310 __regmap_init+0x3151/ 0x4a80 __devm_regmap_init+0x7d/0x100 madera_spi_probe+0x10f/0x333 [madera_spi] spi_probe+0x183/0x210 Actually_probe+0x285/0xc30 Para solucionar este problema, mueva hacia arriba la asignación de rbnode->block inmediatamente después de que la reasignación se haya realizado correctamente para que la estructura de datos permanezca válido incluso si la segunda reasignación falla.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: octeontx2-af: Se corrige posible desreferencia del puntero nulo. Este parche corrige la posible desreferencia del puntero nulo en los archivos "rvu_debugfs.c" y "rvu_nix.c"