Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux,smack: no omitir la comprobación de permisos en el gancho inode_setsecctx Marek Gresko informa que el usuario root en un cliente NFS puede cambiar las etiquetas de seguridad en los archivos de un sistema de archivos NFS que se exporta con el squashing de root habilitado. El final del comentario de kerneldoc para __vfs_setxattr_noperm() indica: * Esta función requiere que el llamador bloquee el i_mutex del inodo antes de * que se ejecute. También supone que el llamador realizará las comprobaciones de permisos * apropiadas. nfsd_setattr() realiza comprobaciones de permisos a través de fh_verify() y nfsd_permission(), pero estos no realizan todas las mismas comprobaciones de permisos que realizan security_inode_setxattr() y sus ganchos LSM relacionados. Dado que nfsd_setattr() es el único consumidor de security_inode_setsecctx(), la solución más sencilla parece ser reemplazar la llamada a __vfs_setxattr_noperm() con una llamada a __vfs_setxattr_locked(). Esto soluciona el problema anterior y tiene el beneficio adicional de hacer que nfsd recupere las delegaciones conflictivas en un archivo cuando un cliente intenta cambiar su etiqueta de seguridad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binfmt_elf_fdpic: se corrige el cálculo del tamaño de AUXV cuando se define ELF_HWCAP2 create_elf_fdpic_tables() no tiene en cuenta correctamente el espacio para el vector AUX cuando una arquitectura tiene definido ELF_HWCAP2. Antes del commit 10e29251be0e ("binfmt_elf_fdpic: fix /proc//auxv"), esto provocaba que la última entrada del vector AUX se estableciera en cero, pero con ese cambio se produce un ERROR del kernel. Corrija esto añadiendo uno al número de entradas AUXV (nitems) cuando se define ELF_HWCAP2.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige un Use After Free al encontrar errores dentro de btrfs_submit_chunk() [BUG] Hay un informe interno de que KASAN informa un Use After Free, con el siguiente backtrace: BUG: KASAN: slab-use-after-free en btrfs_check_read_bio+0xa68/0xb70 [btrfs] Lectura de tamaño 4 en la dirección ffff8881117cec28 por la tarea kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 No contaminado 6.11.0-rc2-next-20240805-default+ #76 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 01/04/2014 Cola de trabajo: btrfs-endio btrfs_end_bio_work [btrfs] Seguimiento de llamadas: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Asignado por la tarea 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] enviar_extensión_página+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] lectura_páginas+0x1a7/0xc60 caché_página_sin_límites+0x2ad/0x560 mapa_archivo_obtener_páginas+0x629/0xa20 mapa_archivo_leer+0x335/0xbf0 lectura_vfs+0x790/0xcb0 lectura_ksys+0xfd/0x1d0 llamada_al_sistema_64+0x6d/0x140 entrada_SYSCALL_64_después_hwframe+0x4b/0x53 Liberado por la tarea 20917: pila_guardado_kasan+0x37/0x60 pista_guardado_kasan+0x10/0x30 información_libre_guardado_kasan+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs_submit_bio+0x33/0x7 0 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSA] Aunque no puedo reproducir el error, el informe en sí es lo suficientemente bueno como para determinar la causa. El seguimiento de llamadas es el contexto de la cola de trabajo de endio normal, pero el seguimiento de liberación por tarea muestra que durante btrfs_submit_chunk() ya encontramos un error crítico y está llamando a btrfs_bio_end_io() para que se solucione el error. Y la función endio original llamó a bio_put() para liberar todo el bio. Esto significa una doble liberación, lo que provoca un Use After Free, por ejemplo: 1. Ingrese a btrfs_submit_bio() con una biografía leída La longitud de la biografía leída es de 128K, cruzando dos franjas de 64K. 2. La primera ejecución de btrfs_submit_chunk() 2.1 Llame a btrfs_map_block(), que devuelve 64K 2.2 Llame a btrfs_split_bio() Ahora hay dos biografías, una que hace referencia a los primeros 64K, la otra que hace referencia a los segundos 64K. 2.3 Se envía la primera mitad. 3. La segunda ejecución de btrfs_submit_chunk() 3.1 Llamar a btrfs_map_block(), que de alguna manera falló Ahora llamamos a btrfs_bio_end_io() para manejar el error 3.2 btrfs_bio_end_io() llama a la función endio original que es end_bbio_data_read(), y llama a bio_put() para el bio original. Ahora el bio original está liberado. 4. El primer bio de 64K enviado terminó Ahora llamamos a btrfs_check_read_bio() e intentamos avanzar el iter del bio. Pero como el bio original (y por lo tanto su iter) ya está liberado, activamos el use-after free anterior. E incluso si la memoria no está envenenada/corrompida, luego llamaremos a la función endio original, causando una doble liberación. [SOLUCIÓN] En lugar de llamar a btrfs_bio_end_io(), --truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: se corrige el acceso fuera de los límites cuando z_erofs_gbuf_growsize() falla parcialmente Si z_erofs_gbuf_growsize() falla parcialmente en un búfer global debido a un error en la asignación de memoria o inyección de fallas (como lo informó syzbot [1]), se deben liberar nuevas páginas comparándolas con las páginas existentes para evitar fugas de memoria. Sin embargo, la matriz gbuf->pages[] anterior puede no ser lo suficientemente grande, lo que puede provocar un acceso fuera de los límites o una desreferencia de ptr nula. Corrija esto verificando con gbuf->nrpages de antemano. [1] https://lore.kernel.org/r/000000000000f7b96e062018c6e3@google.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corregir nfsd4_deleg_getattr_conflict en presencia de una concesión de terceros No es seguro desreferenciar fl->c.flc_owner sin confirmar primero que fl->fl_lmops es el administrador esperado. nfsd4_deleg_getattr_conflict() prueba fl_lmops pero ignora en gran medida el resultado y asume que flc_owner es una nfs4_delegation de todos modos. Esto es incorrecto. Con este parche restauramos el caso "!= &nfsd_lease_mng_ops" para que se comporte como lo hacía antes del cambio mencionado a continuación. Esto es lo mismo que el código actual, pero sin ninguna referencia a una posible delegación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: Move unregister out of atomic section El Commit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")' movió la lista de clientes pmic_glink bajo un spinlock, ya que es accedida por la devolución de llamada rpmsg/glink, que a su vez se invoca desde el contexto IRQ. Esto significa que ucsi_unregister() ahora se llama desde el contexto atómico, lo que no es factible ya que espera un contexto durmiente. Se está realizando un esfuerzo para lograr que GLINK invoque sus devoluciones de llamada en un contexto durmiente, pero hasta entonces, programemos la anulación del registro. Un efecto secundario de esto es que ucsi_unregister() ahora puede suceder después de que el procesador remoto, y por lo tanto el enlace de comunicación con él, se haya ido. pmic_glink_send() se modifica con una verificación para evitar la desreferencia de puntero NULL resultante. Sin embargo, esto hace que el usuario sea informado sobre este error mediante la siguiente entrada en el registro del núcleo: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: no se pudo enviar la solicitud de escritura UCSI: -5

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: single: se corrige una posible desreferenciación de NULL en pcs_get_function(). pinmux_generic_get_function() puede devolver NULL y el puntero 'función' se desreferenciaba sin comprobar si era NULL. Se ha añadido la comprobación del puntero 'función' en pcs_get_function(). Se ha encontrado mediante una revisión de código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb/client: evitar desreferenciar rdata=NULL en smb2_new_read_req() Esto sucede cuando se llama desde SMB2_read() mientras se usa rdma y se alcanza rdma_readwrite_threshold.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: cmd-db: Asignar memoria compartida como WC, no como WB Linux no escribe en la región cmd-db. Esta región de memoria está protegida contra escritura por XPU. En ocasiones, XPU puede detectar erróneamente la expulsión de caché limpia como "escritura" en la región protegida contra escritura, lo que genera una interrupción segura que provoca un bucle sin fin en algún lugar de la Zona de confianza. La única razón por la que funciona en este momento es porque Qualcomm Hypervisor asigna la misma región que la memoria no almacenable en caché en las tablas de traducción de la Etapa 2. El problema se manifiesta si queremos usar otro hipervisor (como Xen o KVM), que no sabe nada sobre esas asignaciones específicas. Cambiar la asignación de memoria cmd-db de MEMREMAP_WB a MEMREMAP_WT/WC elimina la dependencia de las asignaciones correctas en las tablas de la Etapa 2. Este parche corrige el problema actualizando la asignación a MEMREMAP_WC. Probé esto en SA8155P con Xen.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: evitar pánico para archivos cerrados nfsv4.0 en nfs4_show_open Antes del commit 3f29cc82a84c ("nfsd: separar sc_status de sc_type") states_show() dependía de que el campo sc_type fuera de un tipo válido antes de llamar a una subfunción para mostrar el contenido de un stateid en particular. A partir de esa confirmación, dividimos la validez del stateid en sc_status y ya no cambiamos sc_type a 0 mientras deshacemos el hash del stateid. Esto resultó en un error del kernel para las aperturas nfsv4.0 que permanecen y en nfs4_show_open() se desreferenciaba sc_file que era NULL. En cambio, para los stateids abiertos y cerrados, renunciamos a mostrar información que depende de tener un sc_file válido. Para reproducir: monte el servidor con 4.0, lea y cierre un archivo y luego en el servidor cat /proc/fs/nfsd/clients/2/states [ 513.590804] Rastreo de llamadas: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0 [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896] seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [513.592241] ksys_read+0xcc/0x178

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: evitar UAF alrededor de la cerca de preempción El bloqueo de la cerca es parte de la cola, por lo tanto, en el diseño actual, cualquier cosa que bloquee la cerca también debe contener una referencia a la cola para evitar que la cola se libere. Sin embargo, actualmente parece que le enviamos una señal a la cerca y luego descartamos la referencia de la cola, pero si algo está esperando en la cerca, el que espera es expulsado para que se despierte en algún momento posterior, donde al despertarse primero toma el bloqueo antes de verificar el estado de la cerca. Pero si ya descartamos la referencia de la cola, entonces el bloqueo ya podría estar liberado como parte de la cola, lo que lleva a uaf. Para evitar esto, mueva el bloqueo de la cerca a la cerca misma para que no nos encontremos con problemas de duración de vida. La alternativa podría ser tener un bloqueo a nivel de dispositivo, o solo liberar la cola en la devolución de llamada de liberación de la cerca, sin embargo, eso podría requerir enviar a otro trabajador para evitar problemas de bloqueo. Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454 Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342 Referencias: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020 (seleccionada del commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: cambiar ipsec_lock de spin lock a mutex en el commit citado, se agrega bond->ipsec_lock para proteger ipsec_list, por lo tanto, se llaman xdo_dev_state_add y xdo_dev_state_delete dentro de este bloqueo. Como ipsec_lock es un spin lock y tales operaciones xfrmdev pueden dormir, se activará "programación mientras es atómica" al cambiar el esclavo activo de bond. [ 101.055189] ERROR: programación mientras es atómica: bash/902/0x00000200 [ 101.055726] Módulos vinculados en: [ 101.058211] CPU: 3 PID: 902 Comm: bash No contaminado 6.9.0-rc4+ #1 [ 101.058760] Nombre del hardware: [ 101.059434] Seguimiento de llamadas: [ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? opción_almacenamiento_sysfs_bonding+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] cambio_enlace_esclavo_activo+0x392/0x900 [enlace] [ 101.069868] opción_enlace_esclavo_activo_conjunto+0x1c2/0x240 [enlace] [ 101.070454] __opción_enlace_conjunto+0xa6/0x430 [enlace] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [vinculación] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [vinculación] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [vinculación] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Como bond_ipsec_add_sa_all y bond_ipsec_del_sa_all solo se llaman desde bond_change_active_slave, que requiere mantener el bloqueo RTNL. Y bond_ipsec_add_sa y bond_ipsec_del_sa son API xdo_dev_state_add y xdo_dev_state_delete de estado xfrm, que están en el contexto del usuario. Por lo tanto, ipsec_lock no tiene que ser un bloqueo de giro; cámbielo a mutex y, por lo tanto, se puede resolver el problema anterior.