Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrección de lectura use-after-free en tipc_named_reinit syzbot encontró el siguiente problema en: ================================================================== BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764 CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted 5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 [...] ================================================================== En el commit d966ddcc3821 ("tipc: corregir un bloqueo al vaciar el trabajo programado"), la función cancel_work_sync() solo se asegura de que SOLO el trabajo tipc_net_finalize_work() se esté ejecutando/pendiente en cualquier CPU que se haya completado antes de que el espacio de nombres tipc se destruya mediante tipc_exit_net(). Pero esta función no garantiza que el trabajo sea el último en cola. Por lo tanto, se puede acceder a la instancia destruida en el trabajo que intentará ponerse en cola más tarde. Para solucionarlo por completo, reordenamos la llamada de cancel_work_sync() para asegurarnos de que el trabajo tipc_net_finalize_work() se haya puesto en cola por última vez y se deba completar llamando a cancel_work_sync().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corregir fuga de request_sock en ayudantes de búsqueda de sk Un cliente informó de una fuga de request_socket en un entorno de nube de Calico. Descubrimos que un programa BPF estaba realizando una búsqueda de socket con toma un refcnt en el socket y que estaba encontrando el request_socket pero devolviendo el socket LISTEN principal a través de sk_to_full_sk() sin decrementar primero el socket de solicitud secundario, lo que resultaba en una fuga de objeto slab request_sock. Este parche conserva el comportamiento existente de devolver calcetines completos al llamador, pero también decrementa el request_socket secundario si hay uno presente antes de hacerlo para evitar la fuga. Gracias a Curtis Taylor por toda la ayuda para diagnosticar y probar esto. Y gracias a Antoine Tenart por el reproductor y la entrada del parche. La versión 2 de este parche contiene una refactorización según las sugerencias de Daniel Borkmann para validar los indicadores de RCU en el socket de escucha de modo que se equilibre con bpf_sk_release() y actualizar los comentarios según la sugerencia de Martin KaFai Lau. Un pequeño cambio a la sugerencia de Daniel: poner "sk = sk2" debajo de "if (sk2 != sk)" para evitar una instrucción adicional.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: el uso de get_random_u32 en lugar de prandom bh podría ocurrir mientras se actualiza rnd_state por CPU desde el contexto del usuario, es decir, la ruta local_out. ERROR: uso de smp_processor_id() en código preemptible [00000000]: el llamador de nginx/2725 es nft_ng_random_eval+0x24/0x54 [nft_numgen] Rastreo de llamadas: check_preemption_disabled+0xde/0xe0 nft_ng_random_eval+0x24/0x54 [nft_numgen] Use el controlador aleatorio en su lugar, esto también evita la necesidad de un estado prandom local. Además, prandom ahora usa el controlador aleatorio desde d4150779e60f ("random32: use real rng for non-deterministic randomness"). Basado en un parche anterior de Pablo Neira.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: filemap: Manejar entradas hermanas en filemap_get_read_batch() Si una lectura compite con una invalidación seguida de otra lectura, es posible que un folio sea reemplazado por un folio de orden superior. Si eso sucede, veremos una entrada hermana para el nuevo folio en la siguiente iteración del bucle. Esto se manifiesta como una desreferencia de puntero NULL mientras se mantiene el bloqueo de lectura de RCU. Gestiona esto simplemente regresando. La siguiente llamada encontrará el nuevo folio y lo manejará correctamente. Las otras formas de gestionar esta rara ejecución son más complejas y simplemente no vale la pena.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: añadir actualizaciones de TID faltantes en la desactivación de slab La ruta rápida en slab_alloc_node() asume que c->slab es estable siempre que el TID permanezca igual. Sin embargo, dos lugares en __slab_alloc() actualmente no actualizan el TID al desactivar el slab de la CPU. Si varias operaciones se ejecutan en la dirección correcta, esto podría provocar que se pierda un objeto; o, en una situación aún más improbable, incluso podría provocar que se libere un objeto en la lista libre del slab incorrecto, lo que arruina el contador `inuse` y eventualmente provoca que se libere una página al asignador de páginas mientras aún contiene objetos slab. (En realidad no he probado estos casos, esto se basa simplemente en mirar el código. Escribir casos de prueba para estas cosas parece que sería una molestia...) La ejecución que lleva a la inconsistencia de estado es (todas las operaciones en la misma CPU y kmem_cache): - task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu_ptr() (enables preemption) - [PREEMPT B->A] - task A: finish do_slab_free(): - this_cpu_cmpxchg_double() succeeds() - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL] From there, the object on c->freelist will get lost if task B is allowed to continue from here: It will proceed to the retry_load_slab label, set c->slab, then jump to load_freelist, which clobbers c->freelist. But if we instead continue as follows, we get worse corruption: - task A: run __slab_free() on object from other struct slab: - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial) - task A: run slab_alloc_node() with NUMA node constraint: - fastpath fails (c->slab is NULL) - call __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - c->slab is NULL: goto new_slab - slub_percpu_partial() is non-NULL - set c->slab to slub_percpu_partial(c) - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects from slab-2] - goto redo - node_match() fails - goto deactivate_slab - existing c->freelist is passed into deactivate_slab() - inuse count of slab-1 se decrementa para tener en cuenta el objeto de slab-2 En este punto, el conteo de objetos en uso de slab-1 es 1 menos de lo que debería ser. Esto significa que si liberamos todos los objetos asignados en slab-1 excepto uno, SLUB pensará que slab-1 está completamente sin usar y puede liberar su página, lo que lleva a un use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ibmvfc: Asignar/liberar recurso de cola solo durante sondeo/eliminación Actualmente, las subcolas y los recursos del grupo de eventos se asignan/liberan para cada evento de conexión CRQ, como reinicio y LPM. Esto expone al controlador a un par de problemas. Primero, la ineficiencia de liberar y reasignar memoria que simplemente se puede reiniciar después de ser saneada. Además, un sistema bajo presión de memoria corre el riesgo de fallas de asignación que podrían resultar en un controlador paralizado. Finalmente, hay una ventana de ejecución donde el envío/finalización de comandos puede intentar extraer/devolver elementos desde/hacia un grupo de eventos que se está eliminando o que ya se ha eliminado debido a la falta de estado del host en torno a la liberación/asignación de recursos. El siguiente es un ejemplo de corrupción de lista después de una migración de partición en vivo (LPM): Oops: Excepción en modo kernel, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nft_counter nft_compat nf_tables nfnetlink rpadlpar_io rpaphp xsk_diag nfsv3 nfs_acl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth vmx_crypto dm_multipath dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse CPU: 0 PID: 2108 Comm: ibmvfc_0 Kdump: loaded Not tainted 5.14.0-70.9.1.el9_0.ppc64le #1 NIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10 REGS: c00000025c10b760 TRAP: 0700 Not tainted (5.14.0-70.9.1.el9_0.ppc64le) MSR: 800000000282b033 CR: 2800028f XER: 0000000f CFAR: c0000000001f55bc IRQMASK: 0 GPR00: c0000000007c4bac c00000025c10ba00 c000000002a47c00 000000000000004e GPR04: c0000031e3006f88 c0000031e308bd00 c00000025c10b768 0000000000000027 GPR08: 0000000000000000 c0000031e3009dc0 00000031e0eb0000 0000000000000000 GPR12: c0000031e2ffffa8 c000000002dd0000 c000000000187108 c00000020fcee2c0 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c008000002f81300 GPR24: 5deadbeef0000100 5deadbeef0000122 c000000263ba6910 c00000024cc88000 GPR28: 000000000000003c c0000002430a0000 c0000002430ac300 000000000000c300 NIP [c0000000007c4bb0] __list_del_entry_valid+0x90/0x100 LR [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 Call Trace: [c00000025c10ba00] [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 (unreliable) [c00000025c10ba60] [c008000002f42284] ibmvfc_free_queue+0xec/0x210 [ibmvfc] [c00000025c10bb10] [c008000002f4246c] ibmvfc_deregister_scsi_channel+0xc4/0x160 [ibmvfc] [c00000025c10bba0] [c008000002f42580] ibmvfc_release_sub_crqs+0x78/0x130 [ibmvfc] [c00000025c10bc20] [c008000002f4f6cc] ibmvfc_do_work+0x5c4/0xc70 [ibmvfc] [c00000025c10bce0] [c008000002f4fdec] ibmvfc_work+0x74/0x1e8 [ibmvfc] [c00000025c10bda0] [c0000000001872b8] kthread+0x1b8/0x1c0 [c00000025c10be10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 40820034 38600001 38210060 4e800020 7c0802a6 7c641b78 3c62fe7a 7d254b78 3863b590 f8010070 4ba309cd 60000000 <0fe00000> 7c0802a6 3c62fe7a 3863b640 ---[ end trace 11a2b65a92f8b66c ]--- ibmvfc 30000003: Enviar advertencia. Cola de recepción cerrada, se volverá a intentar. Agregue ayudantes de registro/cancelación de registro que se llamen en su lugar durante los restablecimientos de conexión para sanear y reconfigurar las colas.

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xtensa: Fix refcount leak bug in time.c En calibrate_ccount(), of_find_compatible_node() devolverá un puntero de nodo con refcount incrementado. Deberíamos usar of_node_put() cuando ya no se use.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: adi-axi-adc: Se corrige la pérdida de recuento de referencias en adi_axi_adc_attach_client of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no sea necesario. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: aspeed: Se corrige la pérdida de recuento de referencias en aspeed_adc_set_trim_data of_find_node_by_name() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Agregue el error of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: trigger: sysfs: fix use-after-free on remove Asegúrese de que irq_work se haya completado antes de que se libere el disparador.================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25 Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write ==================================================================