Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: arm-ni: corrige la falta de platform_set_drvdata(). Agrega platform_set_drvdata() faltante en arm_ni_probe(); de lo contrario, llamar a platform_get_drvdata() en remove devuelve NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pp: Se corrige una posible desreferencia de puntero nulo en atomctrl_initialize_mc_reg_table. Las funciones atomctrl_initialize_mc_reg_table() y atomctrl_initialize_mc_reg_table_v2_2() no comprueban el valor de retorno de smu_atom_get_data_table(). Si smu_atom_get_data_table() no recupera vram_info, devuelve un valor nulo, que posteriormente se desreferencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: eir: Se solucionan posibles fallos en eir_create_adv_data eir_create_adv_data puede intentar agregar EIR_FLAGS y EIR_TX_POWER sin verificar si encajan.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se corrige la deferencia de puntero NULL en eir_get_service_data El parámetro len se considera opcional, por lo que puede ser NULL y, por lo tanto, no se puede usar para saltar a la siguiente entrada de EIR_SERVICE_DATA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: eliminar la lógica de comprobación de ptp->n_vclocks en ptp_vclock_in_use(). No hay desacuerdo en que debemos comprobar tanto ptp->is_virtual_clock como ptp->n_vclocks para comprobar si el reloj virtual ptp está en uso. Sin embargo, al adquirir ptp->n_vclocks_mux para leer ptp->n_vclocks en ptp_vclock_in_use(), observamos un bloqueo recursivo en el seguimiento de llamadas a partir de n_vclocks_store(). ============================================== ADVERTENCIA: posible bloqueo recursivo detectado 6.15.0-rc6 #1 No contaminado -------------------------------------------- syz.0.1540/13807 está intentando adquirir el bloqueo: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, en: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [en línea] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, en: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 pero la tarea ya tiene el bloqueo: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, en: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** BLOQUEO INTERMEDIO *** .... ============================================== La mejor manera de resolver esto es eliminar la lógica que comprueba ptp->n_vclocks en ptp_vclock_in_use(). Esto es apropiado porque cualquier ruta que use ptp->n_vclocks debe comprobar incondicionalmente si ptp->n_vclocks es mayor que 0 antes de anular el registro de vclocks, y todas las funciones ya están escritas de esta manera. En la función que usa ptp->n_vclocks, ya obtenemos ptp->n_vclocks_mux antes de anular el registro de vclocks. Por lo tanto, necesitamos eliminar la comprobación redundante de ptp->n_vclocks en ptp_vclock_in_use() para evitar el bloqueo recursivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/fhandle.c: se corrige una ejecución en la llamada a has_locked_children(). may_decode_fh() llama a has_locked_children() sin bloqueos. Esta es una ejecución que puede fallar. El resto de los invocadores están seguros, ya que mantienen namespace_sem y se les garantiza un recuento de referencias positivo en el montaje en cuestión. Cambie el nombre de has_locked_children() actual a __has_locked_children(), conviértalo en estático y cambie los usuarios de fs/namespace.c a él. Convierta has_locked_children() en un contenedor para __has_locked_children(), invocándolo bajo read_seqlock_excl(&mount_lock).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Verificar el contenido devuelto por parse_int_array(). El primer elemento de la matriz devuelta almacena su longitud. Si es 0, cualquier manipulación más allá del elemento en el índice 0 termina con null-ptr-deref.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Se corrige la posible desreferencia de PTR nula al inicializar hardware. El resultado de la búsqueda de avs_dai_find_path_template() debe verificarse antes de usarse. Dado que "template" ya se conoce al ejecutar avs_hw_constraints_init(), se omite la búsqueda por completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vm: mover xe_svm_init() antes. En xe_vm_close_and_put(), debemos poder llamar a xe_svm_fini(); sin embargo, durante la creación de la máquina virtual, podemos llamarlo en la ruta de error, antes de haber inicializado realmente el estado de svm, lo que provoca varios splats seguidos de un NPD fatal. (seleccionado del commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seg6: Se corrige la validación de direcciones de siguiente salto. El kernel actualmente valida que la longitud de la dirección de siguiente salto proporcionada no supere la longitud especificada. Esto puede provocar que el kernel lea memoria no inicializada si el espacio de usuario proporcionó una longitud menor que la especificada. Se corrige validando que la longitud proporcionada coincida exactamente con la especificada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrección del acceso nulo en el controlador de contexto de asignación de canal. Actualmente, cuando ath12k_mac_assign_vif_to_vdev() falla, se accede al controlador de radio (ar) desde el controlador VIF del enlace (arvif) para el registro de depuración. Esto es incorrecto. En el escenario de fallo, el controlador de radio es nulo. Corrija el acceso nulo y evite el acceso al controlador de radio migrando a la función auxiliar de registro de depuración de hardware (ath12k_hw_warn). Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/amlogic: Reemplazar smp_processor_id() por raw_smp_processor_id() en meson_ddr_pmu_create(). La función meson_ddr_pmu_create() del controlador PMU DDR de Amlogic utiliza incorrectamente smp_processor_id(), que presupone la preempción deshabilitada. Esto genera advertencias del kernel durante la carga del módulo, ya que meson_ddr_pmu_create() puede invocarse en un contexto preemptible. Siguiente advertencia del kernel y seguimiento de la pila: [ 31.745138] [ T2289] ERROR: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289 [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38 [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0 [ 31.745181] [ T2289] Tainted: [W]=WARN [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT) [ 31.745188] [ T2289] Call trace: [ 31.745191] [ T2289] show_stack+0x28/0x40 (C) [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198 [ 31.745205] [ T2289] dump_stack+0x20/0x50 [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0 [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38 [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745246] [ T2289] platform_probe+0x98/0xe0 [ 31.745254] [ T2289] really_probe+0x144/0x3f8 [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180 [ 31.745261] [ T2289] driver_probe_device+0x54/0x268 [ 31.745264] [ T2289] __driver_attach+0x11c/0x288 [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160 [ 31.745274] [ T2289] driver_attach+0x34/0x50 [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0 [ 31.745281] [ T2289] driver_register+0x78/0x120 [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48 [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438 [ 31.745303] [ T2289] do_init_module+0x68/0x228 [ 31.745311] [ T2289] load_module+0x118c/0x13a8 [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390 [ 31.745320] [ T2289] invoke_syscall+0x74/0x108 [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8 [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48 [ 31.745333] [ T2289] el0_svc+0x60/0x150 [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118 [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0 Los cambios reemplazan smp_processor_id() con raw_smp_processor_id() para garantizar la recuperación segura de la ID de la CPU en contextos preemptibles.