Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Desviado en uno en dm_dmub_outbox1_low_irq(). > ARRAY_SIZE() debe ser >= ARRAY_SIZE() para evitar un acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige la pérdida de recuento de referencias en smb_check_perm_dacl() El problema ocurre en una ruta específica en smb_check_perm_dacl(). Cuando "id" y "uid" tienen el mismo valor, la función simplemente salta del bucle sin disminuir el recuento de referencias del objeto "posix_acls", que se incrementa mediante get_acl() anteriormente. Esto puede provocar fugas de memoria. Arréglelo disminuyendo el recuento de referencias de "posix_acls" antes de saltar a la etiqueta "check_access_bits".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6xxx: Se corrige la fuga de refcount en mv88e6xxx_mdios_register of_get_child_by_name() devuelve un puntero de nodo con refcount incrementado, deberíamos usar of_node_put() en él cuando haya terminado. mv88e6xxx_mdio_register() pasa el nodo del dispositivo a of_mdiobus_register(). No necesitamos el nodo del dispositivo después de él. Agregue of_node_put() faltante para evitar la fuga de refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk_eth_soc: lectura fuera de los límites en mtk_hwlro_get_fdir_entry() La variable "fsp->location" proviene del usuario a través de ethtool_get_rxnfc(). Verifique que sea válida para evitar una lectura fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: amt: se corrige una posible pérdida de memoria en amt_rcv() Si un amt recibe paquetes y encuentra un socket, si no puede encontrar un socket, debería liberar un skb recibido, pero no lo hace, por lo que es posible que se produzca una pérdida de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: dmi-sysfs: Se corrige la pérdida de memoria en dmi_sysfs_register_handle kobject_init_and_add() toma la referencia incluso cuando falla. Según la documentación de kobject_init_and_add(), si esta función devuelve un error, se debe llamar a kobject_put() para limpiar correctamente la memoria asociada con el objeto. Solucione este problema llamando a kobject_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: corregir un bloqueo en __device_attach En la función __device_attach, la lógica de retención de bloqueo es la siguiente: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) Como se muestra arriba, cuando se permite hacer sondeos asincrónicos, debido a falta de memoria o límite de trabajo, no se permite el trabajo asincrónico, para hacer la ejecución sincrónica en su lugar. conducirá a un interbloqueo AA debido a que __device_attach_async_helper obtiene el bloqueo dev. Para solucionar el interbloqueo, mueva async_schedule_dev fuera de device_lock, como podemos ver, en async_schedule_node_domain, el parámetro de queue_work_node es system_unbound_wq, por lo que puede aceptar operaciones simultáneas. lo que tampoco cambiará la lógica del código y no conducirá a un interbloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: tcp_rtx_synack() puede ser llamado desde el contexto del proceso Laurent reportó el informe adjunto [1] Este error se activa con las siguientes condiciones: 0) Kernel construido con CONFIG_DEBUG_PREEMPT=y 1) Se crea un nuevo socket TCP FastOpen pasivo. Este socket FO espera un ACK proveniente del cliente para ser un ACK ESTABLISHED completo. 2) Una operación de socket en este socket pasa por el baile lock_sock() release_sock(). 3) Mientras el socket es propiedad del usuario en el paso 2), se recibe una retransmisión del SYN y se almacena en el backlog del socket. 4) En el momento release_sock(), el backlog del socket se procesa mientras está en el contexto del proceso. 5) Se cocina un paquete SYNACK en respuesta a la retransmisión de SYN. 6) -> tcp_rtx_synack() se llama en el contexto del proceso. Antes de el commit con culpa, tcp_rtx_synack() siempre se llamaba desde el controlador BH, desde un controlador de temporizador. Corrija esto usando TCP_INC_STATS() y NET_INC_STATS() que no asumen que el llamador está en un contexto no preemptible. [1] BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180 caller is tcp_rtx_synack.part.0+0x36/0xc0 CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021 Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: ts4800_wdt: Se corrige la pérdida de recuento de referencias en ts4800_wdt_probe of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Se agrega of_node_put() faltante en algunas rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panfrost: El trabajo debe hacer referencia a MMU, no a file_priv Desde hace un tiempo se ha permitido que un contexto MMU sobreviva a su panfrost_priv correspondiente, sin embargo, la estructura del trabajo aún hace referencia a panfrost_priv para obtener el contexto MMU. Si panfrost_priv se ha liberado, se trata de un use-after-free que he podido activar, lo que ha dado como resultado un splat. Para solucionar esto, elimine la referencia a panfrost_priv en la estructura del trabajo y agregue una referencia directa a la estructura MMU, que es lo que realmente se necesita.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: Se corrige el posible use-after-free en nfsd_file_put() nfsd_file_put_noref() puede liberar @nf, por lo que no desreferencia @nf inmediatamente después del regreso de nfsd_file_put_noref().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/papr_scm: no solicita estadísticas con un búfer de estadísticas de tamaño '0' Sachin informó [1] que en un LPAR POWER-10 está viendo un pánico del kernel que se informa con vPMEM cuando se llama a la sonda papr_scm. El pánico tiene el formato siguiente y se observa solo con la siguiente opción deshabilitada (perfil) para dicho LPAR 'Habilitar recopilación de información de rendimiento' en la HMC: El kernel intentó escribir la página del usuario (1c): ¿intento de explotación? (uid: 0) ERROR: Desreferencia de puntero NULL del kernel al escribir en 0x0000001c Dirección de instrucción con error: 0xc008000001b90844 Oops: Acceso del kernel al área defectuosa, sig: 11 [#1] NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm] LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm] Seguimiento de llamadas: 0xc00000000941bca0 (no confiable) papr_scm_probe+0x2ac/0x6ec [papr_scm] platform_probe+0x98/0x150 really_probe+0xfc/0x510 __driver_probe_device+0x17c/0x230 ---[ fin del seguimiento 0000000000000000 ]--- Pánico del kernel: no se sincroniza: excepción fatal En la investigación, parece que este pánico se produjo debido a que se proporcionó un 'stat_buffer' de tamaño==0 a drc_pmem_query_stats() para obtener todos los identificadores de estadísticas de rendimiento de un NVDIMM. Sin embargo, no se debería haber llamado a drc_pmem_query_stats() ya que el NVDIMM vPMEM no admite ningún identificador de estadísticas de rendimiento. Esto se produjo debido a la falta de verificación de 'p->stat_buffer_len' al comienzo de papr_scm_pmu_check_events(), lo que indica que el NVDIMM no admite estadísticas de rendimiento. Solucione este problema introduciendo la comprobación de 'p->stat_buffer_len' al comienzo de papr_scm_pmu_check_events(). [1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com