Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar comprobación NULL para head_pipe en dcn201_acquire_free_pipe_for_layer Esta confirmación soluciona un posible problema de desreferencia de puntero nulo en la función `dcn201_acquire_free_pipe_for_layer`. El problema podría ocurrir cuando `head_pipe` es nulo. La corrección agrega una comprobación para garantizar que `head_pipe` no sea nulo antes de confirmarlo. Si `head_pipe` es nulo, la función devuelve NULL para evitar una posible desreferencia de puntero nulo. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 Error de dcn201_acquire_free_pipe_for_layer(): anteriormente asumimos que 'head_pipe' podría ser nulo (ver línea 1010)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de múltiples usos [QUÉ Y CÓMO] Los punteros, como stream_enc y dc->bw_vbios, se comprueban como nulos previamente en la misma función, por lo que Coverity advierte "implica que stream_enc y dc->bw_vbios podrían ser nulos". Se utilizan varias veces en el código posterior y es necesario comprobarlos. Esto soluciona 10 problemas de FORWARD_NULL informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de usarlos [QUÉ Y CÓMO] Los punteros, como dc->clk_mgr, se comprueban antes en la misma función, por lo que Coverity advierte que "implica que "dc->clk_mgr" podría ser nulo". Como resultado, estos punteros deben comprobarse cuando se utilicen nuevamente. Esto soluciona 10 problemas de FORWARD_NULL informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de usarlos [QUÉ Y CÓMO] Estos punteros se comprobaron previamente en la misma función, lo que indica que podrían ser nulos, como informó Coverity. Como resultado, deben comprobarse cuando se vuelvan a utilizar. Esto soluciona el problema 3 FORWARD_NULL informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Pasar un valor distinto de nulo a dcn20_validate_apply_pipe_split_flags [QUÉ Y CÓMO] "dcn20_validate_apply_pipe_split_flags" desreferencia la combinación y, por lo tanto, no puede ser un puntero nulo. Pasemos un puntero válido para evitar la desreferencia nula. Esto soluciona 2 problemas de FORWARD_NULL informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: pxafb: Arregla posible use after free en pxafb_task() En la función pxafb_probe, llama a la función pxafb_init_fbinfo, después de lo cual &fbi->task se asocia con pxafb_task. Además, dentro de esta función pxafb_init_fbinfo, la función pxafb_blank dentro de la estructura &pxafb_ops es capaz de programar trabajo. Si eliminamos el módulo que llamará a pxafb_remove para hacer la limpieza, llamará a la función unregister_framebuffer que puede llamar a do_unregister_framebuffer para liberar fbi->fb a través de put_fb_info(fb_info), mientras que se utilizará el trabajo mencionado anteriormente. La secuencia de operaciones que pueden llevar a un error de UAF es la siguiente: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Solucione el problema asegurándose de cancelar el trabajo antes de continuar con la limpieza en pxafb_remove. Tenga en cuenta que solo el usuario root puede eliminar el controlador en tiempo de ejecución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: efifb: Registrar grupos sysfs a través del núcleo del controlador El núcleo del controlador ya puede registrar y limpiar grupos sysfs. Utilice esa funcionalidad para simplificar el manejo y la limpieza de errores. También evite una ejecución UAF durante la anulación del registro donde los atributos sysctl se podían usar después de que se liberara la estructura de información.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu-tasks: Se corrige el acceso a la variable rtpcp percpu inexistente en rcu_tasks_need_gpcb() Para kernels creados con CONFIG_FORCE_NR_CPUS=y, nr_cpu_ids se define como NR_CPUS en lugar del número de CPU posibles, esto provocará el siguiente pánico del sistema: smpboot: Permitiendo 4 CPU, 0 CPU hotplug ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... ERROR: no se puede manejar el error de página para la dirección: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: GW 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Rastreo de llamadas: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Teniendo en cuenta que puede haber agujeros en los números de CPU, utilice el número máximo posible de CPU, en lugar de nr_cpu_ids, para configurar los límites de encolado y desencolado. [ neeraj.upadhyay: Corregir error de compilación de htmldocs informado por Stephen Rothwell ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/ioapic: Manejar errores de asignación con elegancia Breno observó pánicos al usar failslab bajo ciertas condiciones durante el tiempo de ejecución: no se puede asignar irq_pin_list (-1,0,20) Pánico del kernel: no se sincroniza: IO-APIC: no se pudo agregar irq-pin. No se puede continuar panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 Ese es un pánico sin sentido que es un remanente del código IO/APIC histórico que entró en pánico durante el arranque temprano cuando falló la asignación de interrupción. El único lugar que podría justificar el pánico es el código timer_check() de PIT/HPET que intenta averiguar si la interrupción del temporizador se entrega a través de IO/APIC. Pero ese código no requiere manejar fallos de asignación de interrupciones. Si no se puede asignar la interrupción, la entrega del temporizador fallo y entra en pánico debido a eso o vuelve al modo heredado. Solucione esto eliminando el contenedor de pánico alrededor de __add_pin_to_irq_node() y haciendo que mp_irqdomain_alloc() sea consciente de la condición de fallo y la maneje como cualquier otra fallo en esta función de manera elegante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: evitar la lectura fuera de los límites al cargar elementos FW de potencia TX Debido a que loop-expression lo hará una vez más antes de obtener false de cond-expression, el código original copió un tamaño de entrada más allá de la región válida. Solucione el problema moviendo la copia de la entrada a loop-body.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: evitar la desreferencia del puntero NULL iwl_mvm_tx_skb_sta() e iwl_mvm_tx_mpdu() verifican que el puntero mvmvsta no sea NULL. Recupera este puntero utilizando iwl_mvm_sta_from_mac80211, que está desreferenciando el puntero ieee80211_sta. Si sta es NULL, iwl_mvm_sta_from_mac80211 desreferenciará un puntero NULL. Solucione esto comprobando el puntero sta antes de recuperar el mvmsta de él. Si sta no es NULL, entonces mvmsta tampoco lo es.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: arreglo de acceso fuera de los límites a la matriz en las estadísticas de SoC Actualmente, la matriz ath11k_soc_dp_stats::hal_reo_error está definida con un tamaño máximo de DP_REO_DST_RING_MAX. Sin embargo, la función ath11k_dp_process_rx() accede a ath11k_soc_dp_stats::hal_reo_error utilizando el ID de anillo SRNG de destino REO, lo cual es incorrecto. El ID de anillo SRNG difiere del ID de anillo normal, y este uso conduce a un acceso a la matriz fuera de los límites. Para solucionar este problema, modifique ath11k_dp_process_rx() para utilizar el ID de anillo normal directamente en lugar del ID de anillo SRNG para evitar el acceso a la matriz fuera de los límites. Probado en: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1