CVE-2025-22014

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pdr: Corrige el posible bloqueo cuando algún proceso de cliente A llama a pdr_add_lookup() para agregar la búsqueda para el servicio y realiza el trabajo del localizador de programación, más tarde un proceso B obtiene un nuevo paquete de servidor que indica que el localizador está activo y llama a pdr_locator_new_server() que finalmente establece pdr->locator_init_complete en verdadero, lo que hace que el proceso A vea y tome el bloqueo de lista y consulte la lista de dominios, pero se agotará el tiempo de espera debido al bloqueo, ya que la respuesta se pondrá en cola en el mismo qmi->wq y se ordenará workqueue y el proceso B no puede completar el nuevo trabajo de solicitud del servidor debido al bloqueo en el bloqueo de lista. Arréglelo eliminando la iteración de lista innecesaria, ya que la iteración de lista ya se está realizando dentro del trabajo del localizador, así que evítelo aquí y simplemente llame a schedule_work() aquí. Proceso A Proceso B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s error en la espera de la transacción para obtener la lista de dominios: %d
", req->service_name, ret); Registro de errores de tiempo de espera debido a un bloqueo: "PDR: tms/servreg get domain list txn wait fallo: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110" Gracias a Bjorn y Johan por informarme que esta confirmación también corrige una regresión de audio al usar el pd-mapper dentro del kernel, ya que eso hace que sea más fácil alcanzar esta ejecución. [1]

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: Fix the potential deadlock When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d
", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1]