Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/net: se corrige el manejo incorrecto de respuestas de lectura/escritura negativas falsas. En p9_client_write() y p9_client_read_once(), si el servidor responde incorrectamente con éxito, pero con un recuento de escrituras/lecturas negativo, se consideraría que "escrito" (negativo) <= "rsize" (positivo) porque ambas variables estaban firmadas. Para evitar este problema, desactive el signo de las variables. El reproductor enlazado a continuación ahora falla con el siguiente error en lugar de una referencia de puntero nulo: 9pnet: recuento de RWRITE falso (4294967295 > 3)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: solución alternativa para que sched_yield no ceda en modo de viaje en el tiempo. Es posible que la ejecución de sched_yield por un espacio de usuario no provoque la programación en modo de viaje en el tiempo, ya que no ha transcurrido tiempo. En el caso observado, parece tratarse de un bloqueo de giro del espacio de usuario mal implementado en ASAN. Desafortunadamente, con el viaje en el tiempo, causa una ralentización extrema o incluso un bloqueo, dependiendo de la configuración del kernel (CONFIG_UML_MAX_USERSPACE_ITERATIONS). Para solucionarlo, se contabiliza el tiempo del proceso cada vez que ejecuta una llamada al sistema sched_yield.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: Arregla WARN_ON(!ctx) en __free_event() para init parcial Mueve la llamada get_ctx(child_ctx) y la asignación child_event->ctx para que ocurran inmediatamente después de que se asigne el evento secundario. Asegúrate de que child_event->ctx no sea NULL antes de cualquier ruta de error posterior dentro de las llamadas heritage_event a free_event(), satisfaciendo las suposiciones del código de limpieza. Detalles: No hay una etiqueta Fixes clara, porque este error es un efecto secundario de múltiples confirmaciones interactivas a lo largo del tiempo (hasta 15 años de antigüedad), no una sola regresión. El código inicialmente incrementó refcount y luego asignó contexto inmediatamente después de que se creara child_event. Más tarde, se agregó una comprobación de validez temprana para child_event antes de refcount/assignment. Incluso más tarde, se agregó una comprobación de limpieza WARN_ON_ONCE(), asumiendo que event->ctx es válido si pmu_ctx es válido. El problema radica en que WARN_ON_ONCE() podría activarse después de que se supere la comprobación inicial, pero antes de que se asignara child_event->ctx, incumpliendo su precondición. La solución es asignar child_event->ctx justo después de su validación inicial. Esto garantiza la existencia del contexto para cualquier comprobación o rutina de limpieza posterior, resolviendo WARN_ON_ONCE(). Para solucionarlo, posponga la actualización del recuento de referencias y la asignación de child_event->ctx justo después de que se configure child_event->pmu_ctx, pero antes de comprobar si el evento principal está huérfano. La rutina de limpieza depende de que event->pmu_ctx no sea NULL antes de verificar que event->ctx no sea NULL. Esto también mantiene la intención original del autor de pasar child_ctx a find_get_pmu_context antes de su recuento de referencias/asignación. [mingo: Registro de cambios ampliado de otro correo electrónico de Gabriel Shahrouzi].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige el bloqueo entre rcu_tasks_trace y event_mutex. Se corrige el siguiente bloqueo: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegue trace_set_clr_event() a workqueue para evitar dicha dependencia de bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: impide el bloqueo en caso de fallo del entrenamiento del enlace [Por qué] Cuando el entrenamiento del enlace falla, el reloj físico se desactiva. Sin embargo, en enable_streams, se asume que el entrenamiento del enlace se realizó correctamente y el multiplexor selecciona el reloj físico, lo que provoca un bloqueo al escribir en un registro. [Cómo] Cuando se alcanza enable_stream, se comprueba si el entrenamiento del enlace ha fallado. En caso afirmativo, se recurre al reloj de referencia para evitar un bloqueo y mantener el sistema en un estado recuperable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: disminuir sc_count directamente si no se puede poner en cola dl_recall Se produjo una advertencia de bloqueo al invocar nfs4_put_stid después de una operación de cola dl_recall fallida: T1 T2 nfs4_laundromat nfs4_get_client_reaplist nfs4_anylock_blockers __break_lease spin_lock // ctx->flc_lock spin_lock // clp->cl_lock nfs4_lockowner_has_blockers locks_owner_has_blockers spin_lock // flctx->flc_lock nfsd_break_deleg_cb nfsd_break_one_deleg nfs4_put_stid refcount_dec_and_lock spin_lock // clp->cl_lock Cuando se abre un archivo, se genera una nfs4_delegation asignado con sc_count inicializado a 1, y el file_lease contiene una referencia a la delegación. El file_lease se asocia entonces con el archivo a través de kernel_setlease. La disociación se realiza en nfsd4_delegreturn mediante la siguiente cadena de llamadas: nfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg --> nfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_lease La referencia sc_count correspondiente se liberará después de esta disociación. Dado que nfsd_break_one_deleg se ejecuta mientras mantiene el flc_lock, el proceso de disociación se bloquea al intentar adquirir flc_lock en generic_delete_lease. Esto significa: 1) sc_count en nfsd_break_one_deleg no se decrementará a 0; 2) El `nfs4_put_stid` llamado por `nfsd_break_one_deleg` no intentará adquirir `cl_lock`; 3) Por consiguiente, no se crea ninguna condición de interbloqueo. Dado que `sc_count` en `nfsd_break_one_deleg` permanece distinto de cero, podemos ejecutar `refcount_dec` en `sc_count` directamente. Este enfoque evita eficazmente la activación de advertencias de interbloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: txgbe: se corrige pérdida de memoria en la ruta de error txgbe_probe() Cuando se llama a txgbe_sw_init(), se asigna memoria para wx->rss_key en wx_init_rss_key(). Sin embargo, en la función txgbe_probe(), las rutas de error posteriores a txgbe_sw_init() no liberan rss_key. Arréglelo 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 txgbe_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: eth: bnxt: se corrige la falta de recorte del índice de anillo en la ruta de error. La confirmación bajo "Correcciones" convirtió tx_prod para que se ejecutara libremente, pero no lo enmascaró en la ruta de error de Tx. Esto falla en condiciones de error, por ejemplo, cuando falla la asignación de DMA.

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.