Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: PAD: corrige fallo en exit_round_robin() El kernel ocasionalmente fallo en cpumask_clear_cpu(), que se llama dentro de exit_round_robin(), porque al ejecutar clear_bit(nr, addr) con nr establecido en 0xffffffff, el cálculo de la dirección puede causar una desalineación dentro de la memoria, lo que lleva al acceso a una dirección de memoria no válida. ---------- ERROR: no se puede manejar la solicitud de paginación del núcleo en ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: cargado Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Código: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 000000000000000 RDX: 000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000e R13: 0000000000000000 R1 4: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Rastreo de llamadas: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 : mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 : crash btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- Para solucionar esto, asegúrese de que tsk_in_cpu[tsk_index] != -1 antes de llamar cpumask_clear_cpu() en exit_round_robin(), tal como se hace en round_robin_cpu(). [ rjw: Edición del tema, evitar actualizaciones al mismo valor ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/xen-netback: evitar UAF en xenvif_flush_hash() Durante la llamada de iteración list_for_each_entry_rcu de xenvif_flush_hash, kfree_rcu no existe dentro de la sección crítica de lectura de rcu, por lo que si se llama a kfree_rcu cuando finaliza el período de gracia de rcu durante la iteración, se produce UAF al acceder a head->next después de que la entrada se libera. Por lo tanto, para resolver esto, debe cambiarlo a list_for_each_entry_safe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: Establecer chandef correcto al iniciar CAC Al iniciar CAC en un modo distinto del modo AP, devuelve un "ADVERTENCIA: CPU: 0 PID: 63 en cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" causado por chandef.chan que es nulo al final de CAC. Solución: Asegúrese de que la definición del canal esté configurada para los diferentes modos al iniciar CAC para evitar obtener un 'chan' NULL al final de CAC. Seguimiento de llamadas: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [acortar asunto, eliminar OCB, reordenar casos para que coincidan con la lista anterior]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath9k_htc: Use __skb_set_length() para restablecer urb antes de volver a enviar Syzbot señala que skb_trim() tiene una comprobación de cordura en la longitud existente del skb, que puede no inicializarse en algunas rutas de error. La intención aquí es claramente solo restablecer la longitud a cero antes de volver a enviar, así que cambie a llamar a __skb_set_length(skb, 0) directamente. Además, __skb_set_length() ya contiene una llamada a skb_reset_tail_pointer(), así que elimine la llamada redundante. El informe de syzbot vino de ath9k_hif_usb_reg_in_cb(), pero hay un uso similar de skb_trim() en ath9k_hif_usb_rx_cb(), cambie ambos mientras estamos en eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: volver a establecer sk_state en CERRADO si fallo la vinculación automática en sctp_listen_start En sctp_listen_start() invocado por sctp_inet_listen(), debería volver a establecer sk_state en CERRADO si sctp_autobind() falla por cualquier motivo. De lo contrario, la próxima vez que se llame a sctp_inet_listen(), si sctp_sk(sk)->reuse ya está establecido mediante setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash se desreferenciará ya que sk_state está ESCUCHANDO, lo que provoca un bloqueo ya que bind_hash es NULL. KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Seguimiento de llamadas: __sys_listen_socket net/socket.c:1883 [en línea] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar comprobación NULL para head_pipe en dcn32_acquire_idle_pipe_for_head_pipe_in_layer Esta confirmación soluciona un posible problema de desreferencia de puntero nulo en la función `dcn32_acquire_idle_pipe_for_head_pipe_in_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 afirmarlo. 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/dcn32/dcn32_resource.c:2690 Error de dcn32_acquire_idle_pipe_for_head_pipe_in_layer(): anteriormente asumimos que 'head_pipe' podría ser nulo (ver línea 2681)

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: 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 ]