Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm/smu11: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE. (Seleccionada de la confirmación da7dc714a8f8e1c9fc33c57cd63583779a3bef71)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: Se corrige el fallo de la cola de trabajo en cma_netevent_work_handler. La estructura rdma_cm_id tiene el miembro "struct work_struct net_work", que se reutiliza para encolar cma_netevent_work_handler()s en cma_wq. El fallo [1] puede ocurrir si se realizan varias llamadas a cma_netevent_callback() en rápida sucesión, lo que encola aún más cma_netevent_work_handler()s para el mismo rdma_cm_id, sobrescribiendo cualquier elemento de trabajo previamente en cola que se haya programado para ejecutarse. Es decir, no hay garantía de que el elemento de trabajo en cola se ejecute entre dos llamadas sucesivas a cma_netevent_callback() y el segundo INIT_WORK sobrescribiría el primer elemento de trabajo (para el mismo rdma_cm_id), a pesar de obtener id_table_lock durante la encola. Además, el análisis drgn [2] indica que es probable que el elemento de trabajo se haya sobrescrito. Para solucionarlo, mueva INIT_WORK() a __rdma_create_id(), de modo que no compita con ninguna queue_work() existente ni con su subproceso de trabajo. [1] Pila de fallos recortada: =============================================== ERROR: desreferencia de puntero NULL del núcleo, dirección: 000000000000008 kworker/u256:6 ... 6.12.0-0... Cola de trabajo: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Seguimiento de llamadas: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 ============================================= [2] drgn crash analysis: >>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9) Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); >>> trace[8]["work"] *(struct work_struct *)0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head *)0xffff924d075924c0, .prev = (struct list_head *)0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, } Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *) In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work); and get_work_pwq() is: static struct pool_workqueue *get_work_pwq(struct work_struct *work) { unsigned long data = atomic_long_read(&work->data); if (data & WORK_STRUCT_PWQ) return work_struct_pwq(data); else return NULL; } WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4) But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtiofs: añadir comprobación del nombre de la fuente en el contexto del sistema de archivos. En ciertos escenarios, por ejemplo, durante las pruebas fuzz, el nombre de la fuente puede ser nulo, lo que podría provocar un pánico del kernel. Por lo tanto, se debe añadir una comprobación adicional del nombre de la fuente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: slab: garantizar que slab->obj_exts esté libre en una página slab recién asignada. ktest reportó recientemente fallos al ejecutar varias pruebas de E/S con buffer con __alloc_tagging_slab_alloc_hook() en la parte superior de la pila de llamadas de fallo. La firma indica una desreferencia de dirección no válida con bits bajos de slab->obj_exts activados. Los bits estaban fuera del rango utilizado por page_memcg_data_flags y objext_flags, por lo que slab_obj_exts() no los enmascaró al obtener el puntero almacenado en slab->obj_exts. El registro de fallos típico se ve así: 00510 No se puede controlar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000010 00510 Información de aborto de memoria: 00510 ESR = 0x0000000096000045 00510 EC = 0x25: DABT (current EL), IL = 32 bits 00510 SET = 0, FnV = 0 00510 EA = 0, S1PTW = 0 00510 FSC = 0x05: level 1 translation fault 00510 Data abort info: 00510 ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000 00510 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 00510 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000 00510 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 00510 Internal error: Oops: 0000000096000045 [#1] SMP 00510 Modules linked in: 00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g189e17946605 #19327 NONE 00510 Hardware name: linux,dummy-virt (DT) 00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190 00510 lr : __kmalloc_noprof+0x150/0x310 00510 sp : ffffff80c87df6c0 00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200 00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001 00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180 00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000 00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700 00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006 00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58 00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556 00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060 00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000 00510 Call trace: 00510 __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P) 00510 __kmalloc_noprof+0x150/0x310 00510 __bch2_folio_create+0x5c/0xf8 00510 bch2_folio_create+0x2c/0x40 00510 bch2_readahead+0xc0/0x460 00510 read_pages+0x7c/0x230 00510 page_cache_ra_order+0x244/0x3a8 00510 page_cache_async_ra+0x124/0x170 00510 filemap_readahead.isra.0+0x58/0xa0 00510 filemap_get_pages+0x454/0x7b0 00510 filemap_read+0xdc/0x418 00510 bch2_read_iter+0x100/0x1b0 00510 vfs_read+0x214/0x300 00510 ksys_read+0x6c/0x108 00510 __arm64_sys_read+0x20/0x30 00510 invoke_syscall.constprop.0+0x54/0xe8 00510 do_el0_svc+0x44/0xc8 00510 el0_svc+0x18/0x58 00510 el0t_64_sync_handler+0x104/0x130 00510 el0t_64_sync+0x154/0x158 00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881) 00510 ---[ end trace 0000000000000000 ]--- 00510 Kernel panic - not syncing: Oops: Fatal exception 00510 SMP: stopping secondary CPUs 00510 Kernel Offset: disabled 00510 CPU features: 0x0000,000000e0,00000410,8240500b 00510 Límite de memoria: ninguno. La investigación indica que estos bits ya están configurados al asignar la página slab y no se ponen a cero tras la asignación. Aún no sabemos con certeza por qué estos fallos han comenzado a ocurrir recientemente, pero independientemente del motivo, es incorrecto no inicializar un campo que se utiliza posteriormente. Para solucionarlo, inicialice slab->obj_exts durante la asignación de la página slab.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: se corrigen fugas de memoria del firmware. Libera la memoria utilizada para almacenar los resultados del procesamiento de la imagen del firmware al descargar el módulo. Se soluciona el problema relacionado de la fuga de la misma memoria si el procesamiento de la imagen del firmware falla durante la carga del módulo. Se garantiza la destrucción de todos los objetos GEM del firmware si falla el procesamiento de la imagen. Se corrigen las fugas de memoria detectadas por Kmemleak al descargar el módulo powervr: objeto sin referencia 0xffff000042e20000 (tamaño 94208): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE. d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H. backtrace (crc dd329dec): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xaa4/0x1f50 [powervr] unreferenced object 0xffff000042d20000 (size 20480): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................ backtrace (crc 395b02e3): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xb0c/0x1f50 [powervr]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: prime: fix ttm_bo_delayed_delete oops Corrige un oops en ttm_bo_delayed_delete que resulta de la desreferenciación de un puntero colgante: Oops: fallo de protección general, probablemente para dirección no canónica 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 No contaminado 6.14.0-rc4-00267-g505460b44513-dirty #216 Nombre del hardware: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 16/01/2024 Cola de trabajo: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290 Código: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffbf9383473d78 R08: 000000000000000 R09: 0000000000000000 R10: 000000000000000 R11: 000000000000000 R12: 6b6b6b6b6b6b6b6b R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0 PKRU: 55555554 Rastreo de llamadas: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 La causa es: - drm_prime_gem_destroy llama a dma_buf_put(dma_buf), que libera la referencia al dma_buf compartido. El recuento de referencias es 0, por lo que el dma_buf se destruye, lo que a su vez reduce el recuento de referencias amdgpu_bo correspondiente a 0, y el amdgpu_bo se destruye. - Se llama a drm_gem_object_release y luego a dma_resv_fini (que destruye el objeto de reserva), liberando finalmente el amdgpu_bo. - nouveau_bo obj->bo.base.resv ahora es un puntero colgante a la memoria anteriormente asignada a amdgpu_bo. - nouveau_gem_object_del llama a ttm_bo_put(&nvbo->bo), que a su vez llama a ttm_bo_release, que programa ttm_bo_delayed_delete. - ttm_bo_delayed_delete se ejecuta y desreferencia el puntero colgante resv, lo que genera un fallo de protección general. Para solucionar esto, mueva la llamada drm_prime_gem_destroy de nouveau_gem_object_del a nouveau_bo_del_ttm. Esto garantiza que se ejecute después de ttm_bo_delayed_delete.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vma: añadir la opción give_up_on_oom en modificar/fusionar, usar en la versión uffd Actualmente, si una fusión de VMA falla debido a una condición OOM que surge en la fusión de confirmación o un fallo al duplicar anon_vma, informamos de ello para que el llamador pueda gestionarlo. Sin embargo, hay casos en los que el llamador solo está intentando una fusión ostensiblemente y no le importa si falla debido a esta condición. Dado que no queremos introducir una suposición implícita de que solo modificamos realmente los VMA después de que puedan surgir condiciones OOM, agregue una opción 'renunciar a oom' y haga un contrato explícito de que, si se establece este indicador, no modificaremos en absoluto ningún VMA si surge OOM y simplemente nos retiraremos. Dado que sería muy inusual que un usuario intentara usar vma_modify() con este indicador activado, pero especificando un rango dentro de un VMA que termina dividiéndose (lo cual puede fallar debido a problemas con rlimit, no solo por OOM), añadimos una advertencia de depuración para esta condición. El motivo es la versión de uffd: syzkaller (y el astuto análisis de Pedro Falcato) encontró una forma en la que un fallo inyectado en la asignación, que desencadena una condición OOM al fusionar las confirmaciones, provocaba que el código de uffd se confundiera y tratara un valor de error como si fuera un puntero a un VMA. Para evitar esto, utilizamos este nuevo indicador VMG para asegurarnos de que esto nunca ocurra, aprovechando que, si borramos VMAs completas, no queremos que se nos informe de un evento OOM. Muchas gracias a Pedro Falcato por su excelente análisis y a Jann Horn por su perspicaz e inteligente análisis de la situación, ambos fundamentales en esta solución.