Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: rechaza el modo cocinado si se configura junto con otras banderas. Es posible configurar simultáneamente las banderas MONITOR_FLAG_COOK_FRAMES y MONITOR_FLAG_ACTIVE en la misma interfaz de monitor desde el espacio de usuario. Esto provoca que se cree una subinterfaz sin el bit IEEE80211_SDATA_IN_DRIVER configurado, ya que la interfaz de monitor está en estado cocinado y tiene prioridad sobre todos los demás estados. Al eliminar la interfaz, el kernel llama a WARN_ONCE() desde check_sdata_in_driver() debido a la falta de ese bit. Solucione esto rechazando MONITOR_FLAG_COOK_FRAMES si se configura junto con otras banderas. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: regulatory: improve invalid hints checking Syzbot sigue reportando un problema [1] que ocurre cuando símbolos erróneos enviados desde el espacio de usuario se introducen en user_alpha2[] mediante la llamada regulatory_hint_user(). Estas sugerencias regulatorias inválidas deben rechazarse. Si bien una comprobación de seguridad del commit 47caf685a685 ("cfg80211: regulatory: reject invalid hints") parece ser suficiente para evitar estos casos, existe una forma de evitarla por dos razones: 1) El funcionamiento de isalpha() permite usar símbolos distintos de las letras latinas mayúsculas y minúsculas para determinar un país o dominio. Por ejemplo, las letras griegas también se considerarán mayúsculas y minúsculas, y para estos caracteres isalpha() también devolverá verdadero. Sin embargo, los códigos ISO-3166-1 alpha2 solo deben contener caracteres latinos. 2) Al procesar una solicitud regulatoria de usuario, entre reg_process_hint_user() y regulatory_hint_user() se produce una llamada a queue_regulatory_request() que modifica las letras en request->alpha2[] con toupper(). Esto funciona correctamente con símbolos latinos, pero no tanto con caracteres de letras extrañas de la segunda parte de _ctype[]. Syzbot genera una advertencia en is_user_regdom_saved() al enviar primero una letra no latina inesperada que toupper() malforma en un carácter que falla la comprobación de isalpha(). Para evitar esto, mejore is_an_alpha2() para garantizar que los símbolos entrantes sean únicamente letras latinas. [1] Informe de Syzbot: ------------[ cortar aquí ]------------ Usuario inesperado alpha2: A? ADVERTENCIA: CPU: 1 PID: 964 en net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [en línea] ADVERTENCIA: CPU: 1 PID: 964 en net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [en línea] ADVERTENCIA: CPU: 1 PID: 964 en net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 Módulos vinculados: CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 No contaminado 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: events_power_efficient crda_timeout_work RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [en línea] RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [en línea] RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 ... Rastreo de llamadas: crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/amd_nb: Utilice rdmsr_safe() en amd_get_mmconfig_range() Xen no ofrece MSR_FAM10H_MMIO_CONF_BASE a todos los invitados. Esto genera la siguiente advertencia: error de acceso a MSR sin marcar: RDMSR desde 0xc0010058 en rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0) Seguimiento de llamadas: xen_read_msr+0x1e/0x30 amd_get_mmconfig_range+0x2b/0x80 quirk_amd_mmconfig_area+0x28/0x100 pnp_fixup_device+0x39/0x50 __pnp_add_device+0xf/0x150 pnp_add_device+0x3d/0x100 pnpacpi_add_device_handler+0x1f9/0x280 acpi_ns_get_device_callback+0x104/0x1c0 acpi_ns_walk_namespace+0x1d0/0x260 acpi_get_devices+0x8a/0xb0 pnpacpi_init+0x50/0x80 do_one_initcall+0x46/0x2e0 kernel_init_freeable+0x1da/0x2f0 kernel_init+0x16/0x1b0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 basado en peculiaridades de un dispositivo "PNP0c01". Considerar MMCFG como deshabilitado es la acción correcta, por lo que no es necesario realizar ningún cambio. Esto probablemente se expuso al corregir los accesores MSR de Xen para que no fueran silenciosamente seguros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: slimbus: mensajería: ID de transacción libre en un escenario de interrupción retrasada. En caso de retraso en la interrupción por cualquier motivo, slim_do_transfer() devuelve un error de tiempo de espera, pero el ID de transacción (TID) no se libera. Esto provoca un acceso no válido a memoria dentro de qcom_slim_ngd_rx_msgq_cb() debido a un TID no válido. Para solucionar el problema, libere el TID en slim_do_transfer() antes de devolver el error de tiempo de espera para evitar accesos no válidos a memoria. Rastreo de llamadas: __memcpy_fromio+0x20/0x190 qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl] vchan_complete+0x2a0/0x4a0 tasklet_action_common+0x274/0x700 tasklet_action+0x28/0x3c _stext+0x188/0x620 run_ksoftirqd+0x34/0x74 smpboot_thread_fn+0x1d8/0x464 kthread+0x178/0x238 ret_from_fork+0x10/0x20 Código: aa0003e8 91000429 f100044a 3940002b (3800150b) ---[ fin de seguimiento 0fe00bec2b975c99 ]--- Pánico del kernel - no sincroniza: Ups: Excepción fatal en la interrupción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: se corrige que nfs_release_folio() no se bloquee mediante la reescritura de kcompactd. Se añade el indicador PF_KCOMPACTD y el asistente current_is_kcompactd() para comprobarlo, de modo que nfs_release_folio() pueda omitir la llamada a nfs_wb_folio() desde kcompactd. De lo contrario, NFS puede bloquearse a la espera de la reescritura inducida por kcompactd, que recurre a NFS (lo que activa la reescritura en NFSD mediante el montaje de bucle invertido de NFS en el mismo host; NFSD se bloquea a la espera de la llamada de XFS a __filemap_get_folio): 6070.550357] INFORMACIÓN: la tarea kcompactd0:58 ha estado bloqueada durante más de 4435 segundos. {--- [58] "kcompactd0" [<0>] folio_wait_bit+0xe8/0x200 [<0>] folio_wait_writeback+0x2b/0x80 [<0>] nfs_wb_folio+0x80/0x1b0 [nfs] [<0>] nfs_release_folio+0x68/0x130 [nfs] [<0>] split_huge_page_to_list_to_order+0x362/0x840 [<0>] migrate_pages_batch+0x43d/0xb90 [<0>] migrate_pages_sync+0x9a/0x240 [<0>] migrate_pages+0x93c/0x9f0 [<0>] compact_zone+0x8e2/0x1030 [<0>] compact_node+0xdb/0x120 [<0>] kcompactd+0x121/0x2e0 [<0>] kthread+0xcf/0x100 [<0>] ret_from_fork+0x31/0x40 [<0>] ret_from_fork_asm+0x1a/0x30 ---} [akpm@linux-foundation.org: corrección de compilación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: evitar el bloqueo en la liberación de cercas El programador pone en cola el procesamiento de liberación de cercas en una cola de trabajo, en lugar de en la función de liberación en sí. Corrige problemas de bloqueo como los siguientes: [ 607.400437] =============================================== [ 607.405755] ADVERTENCIA: posible bloqueo recursivo detectado [ 607.415500] -------------------------------------------- [ 607.420817] weston:zfq0/24149 está intentando adquirir el bloqueo: [ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, en: pvr_gem_object_vunmap+0x40/0xc0 [powervr] [ 607.436728] pero la tarea ya mantiene el bloqueo: [ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, en: dma_buf_ioctl+0x250/0x554 [ 607.451727] otra información que podría ayudarnos a depurar esto: [ 607.458245] Posible escenario de bloqueo inseguro: [ 607.464155] CPU0 [ 607.466601] ---- [ 607.469044] lock(reservation_ww_class_mutex); [ 607.473584] lock(reservation_ww_class_mutex); [ 607.478114] *** BLOQUEO INTERMEDIO ***

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: rcar: Usar raw_spinlock para proteger el acceso a los registros. Usar raw_spinlock para corregir mensajes falsos sobre contexto no válido cuando la depuración de spinlock está habilitada. El bloqueo solo se usa para serializar el acceso a los registros. [ 4.239592] =============================== [ 4.239595] [ ERROR: Contexto de espera no válido ] [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 No contaminado [ 4.239603] ----------------------------- [ 4.239606] kworker/u8:5/76 está intentando bloquear: [ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, en: gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.239641] otra información que podría ayudarnos a depurar esto: [ 4.239643] context-{5:5} [ 4.239646] 5 bloqueos mantenidos por kworker/u8:5/76: [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, en: process_one_work+0x190/0x62c [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Lectura de la propiedad booleana 'frame-master' con un valor. [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, en: process_one_work+0x1b8/0x62c [ 4.254109] #2: ffff00000920c8f8 [ 4.258345] DE: /soc/sound@ec500000/ports/port@1/endpoint: Lectura de la propiedad booleana 'bitclock-master' con un valor. [ 4.264803] (&dev->mutex){....}-{4:4}, en: __device_attach_async_helper+0x3c/0xdc [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, en: __setup_irq+0xa0/0x690 [ 4.264840] #4: [ 4.268872] DE: /soc/sound@ec500000/ports/port@1/endpoint: Lectura de la propiedad booleana 'frame-master' con un valor. [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, en: __setup_irq+0xc4/0x690 [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: base mmc1 en 0x00000000ee100000, velocidad de reloj máxima 200 MHz [ 4.304082] seguimiento de pila: [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 No contaminado 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 [ 4.304092] Nombre del hardware: Renesas Placa Salvator-X (2.ª versión) basada en r8a77965 (DT) [4.304097] Cola de trabajo: async async_run_entry_fn [4.304106] Rastreo de llamadas: [4.304110] show_stack+0x14/0x20 (C) [4.304122] dump_stack_lvl+0x6c/0x90 [4.304131] dump_stack+0x14/0x1c [4.304138] __lock_acquire+0xdfc/0x1584 [4.426274] lock_acquire+0x1c4/0x33c [4.429942] _raw_spin_lock_irqsave+0x5c/0x80 [4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 [ 4.444422] __irq_set_trigger+0x5c/0x178 [ 4.448435] __setup_irq+0x2e4/0x690 [ 4.452012] request_threaded_irq+0xc4/0x190 [ 4.456285] devm_request_threaded_irq+0x7c/0xf4 [ 4.459398] ata1: reanudación del enlace exitosa después de 1 reintento [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0 [ 4.470660] mmc_start_host+0x50/0xac [ 4.474327] mmc_add_host+0x80/0xe4 [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440 [ 4.482094] renesas_sdhi_probe+0x488/0x6f4 [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78 [ 4.491509] platform_probe+0x64/0xd8 [ 4.495178] really_probe+0xb8/0x2a8 [ 4.498756] __driver_probe_device+0x74/0x118 [ 4.503116] driver_probe_device+0x3c/0x154 [ 4.507303] __device_attach_driver+0xd4/0x160 [ 4.511750] bus_para_cada_unidad+0x84/0xe0 [ 4.515588] __device_attach_async_helper+0xb0/0xdc [ 4.520470] async_run_entry_fn+0x30/0xd8 [ 4.524481] process_one_work+0x210/0x62c [ 4.528494] work_thread+0x1ac/0x340 [ 4.532245] kthread+0x10c/0x110 [ 4.535476] ret_de_la_bifurcación+0x10/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: fallo de memoria: actualización del indicador ttu dentro de unmap_poisoned_folio. Serie de parches "mm: fallo de memoria: desasignar correctamente un folio envenenado durante la migración", v3. Se corrigen dos errores durante la migración de folios si este está envenenado. Este parche (de 3): El commit 6da6b1d4a7df ("mm/hwpoison: convertir TTU_IGNORE_HWPOISON en TTU_HWPOISON") introduce TTU_HWPOISON en lugar de TTU_IGNORE_HWPOISON para detener el envío de la señal SIGBUS al acceder a una página con error tras un error de memoria en un folio limpio. Sin embargo, durante la migración de páginas, anon folio debe configurarse con TTU_HWPOISON durante unmap_*(). Para la caché de páginas, necesitamos una política similar a la de hwpoison_user_mappings para configurar este indicador. Por lo tanto, mueva esta política de hwpoison_user_mappings a unmap_poisoned_folio para gestionar esta advertencia correctamente. Se producirá una advertencia durante el envenenamiento de folio de unamp con el siguiente registro: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 365 en mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c Módulos vinculados: CPU: 1 UID: 0 PID: 365 Comm: bash Contaminado: GW 6.13.0-rc1-00018-gacdb4bbda7ab #42 Contaminado: [W]=WARN Nombre del hardware: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0x8fc/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Rastreo de llamadas: try_to_unmap_one+0x8fc/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c ---[fin de seguimiento 0000000000000000 ]--- [mawupeng1@huawei.com: unmap_poisoned_folio(): eliminar el 'mapeo' local sombreado, según Miaohe] Enlace: https://lkml.kernel.org/r/20250219060653.3849083-1-mawupeng1@huawei.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: Fix pick_task_scx() picking nonqueued task when it is called without balance() a6250aa251ea ("sched_ext: Handle cases where pick_task_scx() is called without previous balance_scx()") añadió un workaround para gestionar los casos donde pick_task_scx() se llama sin preceder a balance_scx(), lo cual se debe a un error de clase fair donde pick_taks_fair() puede devolver NULL después de un retorno verdadero de balance_fair(). El workaround detecta cuándo se llama a pick_task_scx() sin preceder a balance_scx() y emula SCX_RQ_BAL_KEEP y activa el kicking para evitar el estancamiento. Desafortunadamente, el código del workaround estaba probando si @prev estaba en SCX para decidir si mantener la tarea en ejecución. Esto es incorrecto ya que la tarea puede estar en SCX pero ya no se puede ejecutar. Esto podría provocar que pick_task_scx() devuelva una tarea no ejecutable, lo que causa confusiones y fallos interesantes. Por ejemplo, un modo de fallo común es que la tarea termine en el estado (!on_rq && on_cpu), lo que puede provocar que los posibles reactivadores entren en bucles de ocupación, lo que puede fácilmente provocar interbloqueos. Solucione esto comprobando si @prev tiene SCX_TASK_QUEUED definido. Esto hace que @prev_on_scx solo se use en un lugar. Abra el código para su uso y mejore el comentario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: Fix bad hist from corrupting named_triggers list Los siguientes comandos provocan un bloqueo: ~# cd /sys/kernel/tracing/events/rcu/rcu_callback ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger bash: echo: error de escritura: argumento no válido ~# echo 'hist:name=bad:keys=common_pid' > trigger Porque ocurre lo siguiente: event_trigger_write() { trigger_process_regex() { event_hist_trigger_parse() { data = event_trigger_alloc(..); event_trigger_register(.., data) { cmd_ops->reg(.., data, ..) [hist_register_trigger()] { data->ops->init() [event_hist_trigger_init()] { save_named_trigger(name, data) { list_add(&data->named_list, &named_triggers); } } } } ret = create_actions(); (return -EINVAL) if (ret) goto out_unreg; [..] ret = hist_trigger_enable(data, ...) { list_add_tail_rcu(&data->list, &file->triggers); <<<---- ¡¡¡SALTAR!!! (¡esto es importante!) [..] out_unreg: event_hist_unregister(.., data) { cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { list_for_each_entry(iter, &file->triggers, list) { if (!hist_trigger_match(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL test->ops->free(test) [event_hist_trigger_free()] { [..] if (data->name) del_named_trigger(data) { list_del(&data->named_list); <<<<-- ¡NUNCA se elimina! } } } } [..] kfree(datos); <<<-- libera el elemento, pero sigue en la lista. La próxima vez que se registre un hist con nombre, se producirá un error de uaf y el kernel podría bloquearse. Desplace el código de forma que, si event_trigger_register() tiene éxito, se llame a hist_trigger_enable(), lo que lo añade a la lista. Se invocan varias acciones si get_named_trigger_data() devuelve falso. Sin embargo, no es necesario llamarlo después de event_trigger_register(), por lo que se puede adelantar, lo que permite llamar a event_trigger_register() justo antes de hist_trigger_enable(), manteniéndolos juntos y permitiendo que los disparadores de archivo se rellenen correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: acpi: typec: ucsi: Introducir un método ->poll_cci. Para el backend ACPI de UCSI, los "registros" UCSI son simplemente una copia en memoria de los valores de registro en una región operativa. La implementación de ACPI en la BIOS garantiza que el contenido de la región operativa se sincronice con el controlador integrado y que los registros (en particular, CCI) se sincronicen con la región operativa en las notificaciones. Si bien existe una llamada ACPI que sincroniza los registros con la región operativa, rara vez es necesario hacerlo y, en algunas implementaciones de ACPI, falla de diversas maneras interesantes. La única razón para forzar una sincronización desde el controlador integrado es sondear CCI mientras las notificaciones están deshabilitadas. Solo el núcleo ucsi sabe si este es el caso y las suposiciones basadas en el comando actual no son óptimas, es decir, conducen al siguiente mensaje de afirmación falsa: ADVERTENCIA: CPU: 3 PID: 76 en drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi] CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 No contaminado 6.12.11-200.fc41.x86_64 #1 Nombre del hardware: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 17/03/2023 Cola de trabajo: events_long ucsi_init_work [typec_ucsi] RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi] Seguimiento de llamadas: ucsi_init_work+0x3c/0xac0 [typec_ucsi] process_one_work+0x179/0x330 workers_thread+0x252/0x390 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 Por lo tanto, introduzca un método ->poll_cci() que funcione como ->read_cci() con una sincronización forzada adicional y documente que debe usarse al sondear con las notificaciones deshabilitadas. Para todos los demás backends que presumiblemente no presenten este problema, utilice la misma implementación para ambos métodos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp i3c: gestiona dirección de encabezado NULL. daddr puede ser NULL si no hay ninguna entrada presente en la tabla de vecinos, en ese caso el paquete tx debe descartarse. saddr generalmente será configurado por el núcleo MCTP, pero verifica si es NULL en caso de que un paquete sea transmitido por un protocolo diferente.