Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: sch: Prioridad de verificación de límites. Nada estaba explícitamente limitado al verificar el índice de prioridad utilizado para acceder a clpriop[]. AVISO y salga temprano si es patológico. Visto con GCC 13: ../net/sched/sch_htb.c: En función 'htb_activate_prios': ../net/sched/sch_htb.c:437:44: advertencia: el subíndice de matriz [0, 31] está fuera de los límites de la matriz de 'struct htb_prio[8]' [-Warray-bounds=] 437 | si (p->inner.clprio[prio].feed.rb_node) | ~~~~~~~~~~~~~~~^~~~~~ ../net/sched/sch_htb.c:131:41: nota: al hacer referencia a 'clprio' 131 | estructura htb_prio clprio[TC_HTB_NUMPRIO]; | ^~~~~~

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: no permita que sock_map_{close,destroy,unhash} se llame a sí mismo. Las devoluciones de llamada del proto sock_map nunca deberían llamarse a sí mismas por diseño. Protéjase contra bugs como [1] y salga del bucle recursivo para evitar un desbordamiento de la pila que favorezca una fuga de recursos. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: no desarmar el valor predeterminado al limpiar el códec. Varias funciones que participan en la inicialización y eliminación del códec son reutilizadas por las implementaciones de controladores de códec ASoC. Los controladores imitan el comportamiento de hda_codec_driver_probe/remove() que se encuentra en sound/pci/hda/hda_bind.c con su componente->probe/remove(). Una de las razones de esto es la expectativa de que snd_hda_codec_device_new() reciba un puntero válido a una instancia de struct snd_card. Esta expectativa sólo podrá cumplirse una vez que comience la investigación de los componentes de la tarjeta de sonido. Como la tarjeta de sonido ASoC puede desconectarse sin que el dispositivo códec se elimine realmente del sistema, desarmar ->preset en snd_hda_codec_cleanup_for_unbind() interfiere con la descarga del módulo -> escenario de carga causando null-ptr-deref. El ajuste preestablecido se asigna solo una vez, durante la coincidencia de dispositivo/controlador, mientras que la recarga del módulo del controlador del códec ASoC puede ocurrir varias veces durante la vida útil de una pila de audio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: bloquea el inodo en modo compartido antes de iniciar fiemap. Actualmente, fiemap no toma el bloqueo del inodo (bloqueo VFS), solo bloquea un rango de archivos en el árbol io del inodo. Sin embargo, esto puede llevar a un punto muerto si tenemos un fsync simultáneo en el archivo y el código fiemap desencadena una falla al acceder al búfer de espacio de usuario con fiemap_fill_next_extent(). El punto muerto ocurre en el semáforo i_mmap_lock del inodo, que es tomado tanto por fsync como por btrfs_page_mkwrite(). Syzbot informó recientemente de este punto muerto y activa un seguimiento como el siguiente: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c: 5293 [en línea] __schedule+0x995/0xe20 kernel/sched/core.c:6606 Schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [en línea] wait_extent_bit +0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc +0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extensión_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extensión_writepages+0x219/0 x540 fs/btrfs/ extend_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [en línea] filemap_fdatawrite_range+0x175/0x200 mm/filemap .c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [en línea] start_ordered_ops fs/btrfs/file.c:1737 [en línea] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs .h:2885 [en línea] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: fffffffffffffda 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFORMACIÓN: tarea syz-executor361:5697 bloqueada durante más de 145 segundos. No contaminado 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-executor361 estado:D pila:21216 pid:5697 ppid:5119 banderas:0x00004004 Seguimiento de llamadas: context_switch kernel/sched/core.c:5293 [en línea] __schedule+0x995/0xe20 kernel/sched/core. c:6606 Schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/ 0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [en línea] __handle_mm_fault mm/memory.c :5073 [en línea] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [en línea] exc_page_fault+ 0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S :233 Código: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/fence: se solucionó el error debido a que drm_sched init/fini no coincide. Actualmente, amdgpu llama a drm_sched_fini() desde la rutina SW fini del controlador de valla; se espera que se llame a dicha función. sólo después de que la función de inicio respectiva, drm_sched_init(), se haya ejecutado correctamente. Sucede que recientemente nos enfrentamos a una falla en la sonda del controlador en Steam Deck, y se llamó a la función drm_sched_fini() incluso sin que su contraparte se hubiera llamado previamente, lo que provocó el siguiente error: amdgpu: la sonda de 0000:04:00.0 falló con error -110 ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000090 PGD 0 P4D 0 Ups: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd No contaminado 6.2.0-rc3-gpiccoli #338 Nombre del hardware : Valve Jupiter/Jupiter, BIOS F7A0113 04/11/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Seguimiento de llamadas: amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [ amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] Para evitar eso, verifique si drm_sched se inicializó correctamente para un anillo determinado antes de llamar a su contraparte fini. Observe que idealmente usaríamos sched.ready para eso; dicho campo se establece como lo último en drm_sched_init(). Pero amdgpu parece "sobreescribir" el significado de dicho campo; en el ejemplo anterior, por ejemplo, fue un anillo GFX el que provocó el bloqueo y el campo sched.ready se configuró en verdadero en la rutina de inicio del anillo, independientemente del estado de el programador DRM. Por lo tanto, terminamos usando sched.ops según la sugerencia de Christian [0] y también eliminamos la verificación no_scheduler [1]. [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994- f85f-d837-609f-7056d5fb7231@amd.com/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Repare la corrupción de la página causada por el control racy en __free_pages. Cuando actualizamos nuestro kernel, comenzamos a ver algunos daños en la página como los siguientes de manera consistente: ERROR: Estado incorrecto de la página en el proceso ganesha.nfsd pfn: 1304ca página:0000000022261c55 refcount:0 mapcount:-128 mapeo:0000000000000000 índice:0x0 pfn:0x1304ca banderas: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 24b35ec08 0000000000000000 raw: 00000000000000000 0000000000000001 00000000ffffff7f 00000000000000000 página volcada porque: recuento de mapas distinto de cero CPU: 0 PID: 15567 Comm : ganesha.nfsd Kdump: cargado Contaminado: PBO 5.10.158-1.nutanix.20221209.el7.x86_64 #1 Nombre del hardware: VMware, Inc. Plataforma virtual VMware/Plataforma de referencia de escritorio 440BX, BIOS 6.00 05/04/2016 Seguimiento de llamadas : dump_stack+0x74/0x96 bad_page.cold+0x63/0x94 check_new_page_bad+0x6d/0x80 rmqueue+0x46e/0x970 get_page_from_freelist+0xcb/0x3f0 ? _cond_resched+0x19/0x40 __alloc_pages_nodemask+0x164/0x300 alloc_pages_current+0x87/0xf0 skb_page_frag_refill+0x84/0x110 ... A veces, también aparecería como corrupción en el puntero de la lista libre y provocaría fallos. Después de dividir el problema en dos, encontramos que el problema comenzó desde la confirmación e320d3012d25 ("mm/page_alloc.c: corrige la liberación de páginas no compuestas"): if (put_page_testzero(page)) free_the_page(page, order); else if (!PageHead(página)) while (orden-- > 0) free_the_page(página + (1 << orden), orden); Entonces, el problema es que la verificación PageHead es picante porque en este punto ya eliminamos nuestra referencia a la página. Entonces, incluso si ingresamos con una página compuesta, la página ya se puede liberar y PageHead puede devolver falso y terminaremos liberando todas las páginas finales causando un double free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s/interrupt: corrige la ejecución de salida de interrupción con un interruptor de mitigación de seguridad. Las opciones de mitigación de seguridad RFI y STF pueden invertir la condición de rama estática interrupt_exit_not_reentrant al mismo tiempo que el código de salida de interrupción que prueba esa rama. . La salida de interrupción prueba esta condición para configurar MSR[EE|RI] para la salida, luego nuevamente en el caso de que se encuentre pendiente una interrupción enmascarada, para recuperar el MSR para que la interrupción pueda reproducirse antes de intentar salir nuevamente. Si la condición cambia entre estas dos pruebas, el estado de la máscara suave MSR e irq se dañará, lo que generará advertencias y posibles fallas. Por ejemplo, si la rama es inicialmente verdadera y luego falsa, MSR[EE] será 0 pero PACA_IRQ_HARD_DIS estará clara y es posible que EE no se habilite, lo que generará advertencias en irq_64.c.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lib/generic-radix-tree.c: No se desborda en peek() Cuando comenzamos a distribuir nuevos números de inodos en la mayor parte del espacio de inodos de 64 bits, eso activó algunas esquinas. errores de casos, en particular algunos desbordamientos de enteros relacionados con el código del árbol de base. Ups.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vdpa: ifcvf: realice una limpieza adecuada si falla el inicio de IFCVF. ifcvf_mgmt_dev pierde memoria si no se libera antes de regresar. Se realiza una llamada para corregir la declaración de devolución para que no se pierda memoria. ifcvf_init_hw no se encarga de esto, por lo que es necesario hacerlo aquí.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: corrige la desreferencia del puntero null para restablecer el decodificador. No todos los decodificadores tienen una devolución de llamada de reinicio. La especificación CXL permite que un puente de host con un único puerto raíz no tenga decodificadores HDM explícitos. Actualmente, el controlador de región supone que no hay ninguno. Como tal, el núcleo CXL crea una instancia de decodificador de paso especial sin una devolución de llamada de confirmación/restablecimiento. Antes de este parche, la devolución de llamada ->reset() se llamaba incondicionalmente al llamar a cxl_region_decode_reset. Por lo tanto, una configuración con 1 puente de host, 1 puerto raíz y un dispositivo CXL tipo 3 conectado directamente o varios dispositivos CXL tipo 3 conectados a puertos descendentes de un conmutador puede provocar una desreferencia de puntero null. Antes de la solución, se observaba un fallo del kernel cuando destruíamos la región y se restablecía un decodificador de paso. El problema se puede reproducir como se muestra a continuación: 1) cree una región con una configuración CXL que incluya un HB con un único puerto raíz bajo el cual se conecta directamente un memdev. 2) destruir la región con cxl destroy-region regionX -f.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: single: corrige una posible desreferencia NULL. Se agregó la verificación de la "función" del puntero en pcs_set_mux(). pinmux_generic_get_function() puede devolver NULL y se eliminó la referencia al puntero "función" sin compararlo con NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: switch: soluciona una posible fuga de memoria en ice_add_adv_recipe(). Cuando ice_add_special_words() falla, el 'rm' no se libera, lo que provocará una pérdida de memoria. Solucione este problema yendo a la etiqueta 'err_unroll'. Compilación probada únicamente.