Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ngbe: corrección de pérdida de memoria en la ruta de error de ngbe_probe() Cuando se llama a ngbe_sw_init(), se asigna memoria para wx->rss_key en wx_init_rss_key(). Sin embargo, en la función ngbe_probe(), las rutas de error posteriores a ngbe_sw_init() no liberan rss_key. Solucione esto liberándolo en la ruta de error junto con wx->mac_table. Cambie también la etiqueta a la que salta la ejecución cuando falla ngbe_sw_init(), porque de lo contrario, podría provocar una doble liberación de rss_key, cuando falla la asignación de mac_table en wx_sw_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igc: corrección de la lógica del disparador del ciclo de PTM Escribir para borrar el bit "valid" de estado de PTM mientras el ciclo de PTM está activado da como resultado un funcionamiento poco fiable de PTM. Para solucionarlo, borre el "trigger" y el estado de PTM después de cada transacción de PTM. El problema se puede reproducir con lo siguiente: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Nota: 1000 Hz (-R 1000) es irrealmente grande, pero proporciona una forma de reproducir rápidamente el problema. PHC2SYS termina con: "ioctl PTP_OFFSET_PRECISE: Connection timed out" cuando falla la transacción de PTM Este parche también corrige un bloqueo en igc_probe() al cargar el controlador igc en el kernel kdump en sistemas compatibles con PTM. El controlador igc que se ejecuta en el kernel base habilita el disparador de PTM en igc_probe(). Por lo tanto, el controlador siempre está en modo de disparo PTM, excepto durante breves periodos al activar manualmente un ciclo PTM. Si se produce un fallo, la NIC se reinicia con el disparo PTM activado. Debido a un problema de hardware, la NIC se encuentra en un estado de busmaster defectuoso y no gestiona las lecturas/escrituras de registros. Al ejecutar igc_probe() en el kernel de kdump, el primer acceso a un registro de la NIC bloquea el sondeo del controlador y, en última instancia, interrumpe kdump. Con esta revisión, igc mantiene el disparo PTM desactivado la mayor parte del tiempo, y solo se activa durante periodos muy breves (10-100 us) al activar manualmente un ciclo PTM. La probabilidad de que se produzca un fallo durante un disparo PTM no es nula, sino extremadamente reducida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Solo crea /proc/fs/netfs con CONFIG_PROC_FS Al probar una configuración especial: CONFIG_NETFS_SUPPORTS=y CONFIG_PROC_FS=n El sistema se bloquea con algo como: [ 3.766197] ------------[ corte aquí ]------------ [ 3.766484] ¡ERROR del kernel en mm/mempool.c:560! [ 3.766789] Oops: código de operación no válido: 0000 [#1] SMP NOPTI [ 3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Contaminado: GW [ 3.767777] Contaminado: [W]=WARN [ 3.767968] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), [ 3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19 [ 3.768847] Código: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00 [ 3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286 [3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000 [3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 000000000ffffffff [3.771217] RBP: 0000000000092880 R08: 000000000000000 R09: ffffc90000013828 [3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0 [3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40 [3.772554] FS: 0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000 [3.773061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0 [ 3.773884] PKRU: 55555554 [ 3.774058] Seguimiento de llamadas: [ 3.774232] [ 3.774371] mempool_alloc_noprof+0x6a/0x190 [ 3.774649] ? _printk+0x57/0x80 [ 3.774862] netfs_alloc_request+0x85/0x2ce [ 3.775147] netfs_readahead+0x28/0x170 [ 3.775395] read_pages+0x6c/0x350 [ 3.775623] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.775928] page_cache_ra_unbounded+0x1bd/0x2a0 [ 3.776247] filemap_get_pages+0x139/0x970 [ 3.776510] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.776820] filemap_read+0xf9/0x580 [ 3.777054] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.777368] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.777674] ? find_held_lock+0x32/0x90 [ 3.777929] ? netfs_start_io_read+0x19/0x70 [ 3.778221] ? netfs_start_io_read+0x19/0x70 [ 3.778489] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.778800] ? lock_acquired+0x1e6/0x450 [ 3.779054] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.779379] netfs_buffered_read_iter+0x57/0x80 [ 3.779670] __kernel_read+0x158/0x2c0 [ 3.779927] bprm_execve+0x300/0x7a0 [ 3.780185] kernel_execve+0x10c/0x140 [ 3.780423] ? __pfx_kernel_init+0x10/0x10 [ 3.780690] kernel_init+0xd5/0x150 [ 3.780910] ret_from_fork+0x2d/0x50 [ 3.781156] ? __pfx_kernel_init+0x10/0x10 [ 3.781414] ret_from_fork_asm+0x1a/0x30 [ 3.781677] [ 3.781823] Modules linked in: [ 3.782065] ---[ fin de seguimiento 0000000000000000 ]--- Esto se debe a la siguiente ruta de error en netfs_init(): if (!proc_mkdir("fs/netfs", NULL)) goto error_proc; Solucione esto agregando ifdef en netfs_main(), de modo que /proc/fs/netfs solo se cree con CONFIG_PROC_FS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: Clear iommu-dma ops on cleanup Si iommu_device_register() encuentra un error, puede terminar derribando grupos ya configurados y dominios predeterminados, sin embargo, esto actualmente todavía deja dispositivos conectados a iommu-dma (e incluso históricamente el comportamiento en esta área era, en el mejor de los casos, inconsistente entre arquitecturas/controladores...) Aunque en el caso de que haya un IOMMU cuyo controlador no haya podido sondear, los usuarios no necesariamente pueden esperar que DMA funcione de todos modos, todavía se puede argumentar que deberíamos hacer todo lo posible para volver a poner las cosas como si el controlador IOMMU nunca hubiera estado allí, y ciertamente el potencial de bloqueo en iommu-dma en sí mismo es indeseable. Asegúrese de limpiar el indicador dev->dma_iommu junto con todo lo demás.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Acceso síncrono entre los subprocesos de reinicio y tm para la cola de respuestas. Cuando el subproceso de gestión de tareas procesa las colas de respuestas mientras el subproceso de reinicio las reinicia, este último accede a un ID de cola no válido (0xFFFF), establecido por el subproceso de reinicio, que apunta a memoria no asignada, lo que provoca un fallo. Se ha añadido el indicador «io_admin_reset_sync» para sincronizar el acceso entre los subprocesos de reinicio, E/S y administración. Antes de un reinicio, el controlador de reinicio establece este indicador para bloquear los subprocesos de procesamiento de E/S y administración. Si algún subproceso omite la comprobación inicial, el subproceso de reinicio espera hasta 10 segundos a que finalice el procesamiento. Si la espera supera los 10 segundos, el controlador se marca como irrecuperable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: pidff: Corrección de la desreferencia de puntero nulo en pidff_find_fields. Esta función activaba una desreferencia de puntero nulo si se utilizaba para buscar un informe no implementado en el dispositivo. Esto ocurría tanto con informes opcionales como obligatorios. Se aplicó la misma lógica a pidff_find_special_field y, aunque pidff_init_fields debería devolver un error antes si falta uno de los informes obligatorios, futuras modificaciones podrían cambiar esta lógica y reaparecer esta posible desreferencia de puntero nulo. Informe de error de LKML: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: no se permite solo datadir. En teoría, overlayfs podría permitir que la capa superior haga referencia directa a una capa de datos, pero actualmente no existe un caso práctico para esto. Originalmente, cuando se introdujeron las capas de solo datos, esto no se permitía; solo se introdujo mediante la función "datadir+", pero sin gestionar este caso, lo que resultaba en un error. Se soluciona deshabilitando datadir sin lowerdir.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: clean up FDB, MDB, VLAN entries on unbind Como se explica en muchos lugares como la confirmación b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add y dsa_legacy_fdb_del"), DSA se escribe asumiendo que las capas superiores tienen adiciones/eliminaciones equilibradas. Como tal, solo tiene sentido ser extremadamente vocal cuando se violan esas suposiciones y el controlador se desvincula con entradas aún presentes. Pero Ido Schimmel señala una situación muy simple donde eso es incorrecto: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (también discutido brevemente por mí en la confirmación mencionada anteriormente). Básicamente, mientras que las operaciones de bypass de puente no son algo que DSA documente explícitamente, y para la mayoría de los controladores DSA esta API simplemente hace que pasen al modo promiscuo, ese no es el caso para todos los controladores. Algunos requisitos para que las operaciones de bypass de puente sean útiles (véase dsa_switch_supports_uc_filtering()). Si bien en tools/testing/selftests/net/forwarding/local_termination.sh nos esforzamos por popularizar mejores mecanismos para gestionar filtros de direcciones en interfaces DSA desde el espacio de usuario (en concreto, macvlan para unidifusión y setsockopt(IP_ADD_MEMBERSHIP) mediante mtools para multidifusión), lo cierto es que «bridge fdb add ... self static local» también existe como UAPI del kernel y podría ser útil, aunque solo sea para una modificación rápida. Parece contraproducente bloquear esa ruta implementando operaciones de shim .ndo_fdb_add y .ndo_fdb_del, que simplemente devuelven -EOPNOTSUPP para impedir la ejecución de ndo_dflt_fdb_add() y ndo_dflt_fdb_del(), aunque podríamos hacerlo. Aceptar la necesidad de una depuración parece ser la única opción. Sobre todo porque parece que también estamos abordando este tema desde una perspectiva diferente. Russell King observa que la función WARN_ON() se activa incluso para las VLAN: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/ Lo que ocurre en el informe de error anterior es que dsa_port_do_vlan_del() falla, la entrada de la VLAN persiste y, a continuación, advertimos sobre la desvinculación y la filtramos. Esto no es una reversión directa de la confirmación criticada, sino que ahora añadimos una impresión informativa al registro del kernel (para seguir viendo la existencia de errores) y algunos comentarios adicionales recopilados de años anteriores para justificar la lógica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6xxx: corrección de -ENOENT al eliminar VLAN y MST no es compatible Russell King informa que en ZII dev rev B, la eliminación de una VLAN de puente de un puerto de usuario falla con -ENOENT: https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/ Esto viene de mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), que intenta encontrar una entrada MST en &chip->msts asociada con el SID, pero falla y devuelve -ENOENT como tal. Pero sabemos que este chip no admite MST en absoluto, por lo que no es sorprendente. La pregunta es por qué la protección en mv88e6xxx_mst_put() no sale antes: if (!sid) return 0; La respuesta parece sencilla: el SID proviene de vlan.sid, que supuestamente se rellenaba previamente con mv88e6xxx_vtu_get(). Sin embargo, algunas implementaciones de chip->info->ops->vtu_getnext() no rellenan vlan.sid; por ejemplo, véase mv88e6185_g1_vtu_getnext(). En ese caso, más adelante en mv88e6xxx_port_vlan_leave(), usamos un SID no válido, que es simplemente memoria de pila residual. La prueba de sid == 0 cubre todos los casos de una VLAN sin puente o una VLAN de puente asignada al MSTI predeterminado. Para algunos chips, el SID 0 es válido y se instala con mv88e6xxx_stu_setup(). Un chip que no admita la STU solo permitiría, implícitamente, la asignación de todas las VLAN al MSTI predeterminado. Por lo tanto, aunque el SID 0 no es válido, bastaría con inicializar a cero la estructura de la VLAN para corregir el error, debido a la coincidencia de que ya existe una prueba para vlan.sid == 0 que produce el mismo comportamiento (correcto). Otra opción suficiente sería añadir una prueba para mv88e6xxx_has_stu() dentro de mv88e6xxx_mst_put(), simétrica a la existente en mv88e6xxx_mst_get(). Sin embargo, esta ubicación implica que el emisor tendrá que desreferenciar vlan.sid, lo que implica acceder a memoria no inicializada, lo cual no es conveniente incluso si lo ignora posteriormente. Por lo tanto, realizamos ambas modificaciones para no depender solo de la coincidencia de sid == 0, sino también para evitar tener campos de estructura sin inicializar a los que se pueda acceder temporalmente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxbf-bootctl: use sysfs_emit_at() en secure_boot_fuse_state_show() Se ve una advertencia al ejecutar el kernel más reciente en un SOC BlueField: [251.512704] ------------[ cortar aquí ]------------ [251.512711] sysfs_emit no válido: buf:0000000003aa32ae [251.512720] ADVERTENCIA: CPU: 1 PID: 705264 en fs/sysfs/file.c:767 sysfs_emit+0xac/0xc8 La advertencia se activa porque el controlador mlxbf-bootctl invoca "sysfs_emit()" con un puntero de búfer que no está alineado con el inicio de la página. En su lugar, el controlador debería utilizar "sysfs_emit_at()" para admitir desplazamientos distintos de cero en el búfer de destino.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: Silenciar la advertencia de kvmalloc() sobredimensionado. syzkaller activó una advertencia de kvmalloc() sobredimensionado. Silénciala añadiendo __GFP_NOWARN. Registro de syzkaller: ADVERTENCIA: CPU: 7 PID: 518 en mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro No contaminado 6.11.0-rc6+ #6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 00000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/userptr: fix notifier vs folio deadlock El usuario informa lo que parece ser un deadlock entre notifier y folio, donde migration_pages_batch() en el lado del núcleo central mantiene el bloqueo de folio y luego interactúa con las asignaciones de este, sin embargo, esas asignaciones están vinculadas a algún userptr, lo que significa llamar a la devolución de llamada del notificador y tomar el bloqueo del notificador. Con una sincronización perfecta, parece posible que las páginas que extrajimos de la falla hmm puedan ser atacadas por migration_pages_batch() al mismo tiempo que mantenemos el bloqueo del notificador para marcar las páginas como accedidas/sucias, pero en este punto también queremos tomar el bloqueo de folio para marcarlos como sucios, pero si se disputan desde el lado de notifier/migrate_pages_batch, entonces nos bloqueamos ya que el bloqueo de folio no se eliminará hasta que eliminemos el bloqueo del notificador. Afortunadamente, mark_page_accessed/dirty no es realmente necesario en primer lugar, al parecer, y ya debería haber sido realizado por hmm fault, así que simplemente elimínelo. (seleccionado del commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)