CVE-2026-89979 in Linuxinformation

Résumé

par VulDB • 16/09/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

ALSA: pcm : Correction d’une condition de course (race) entre les opérations non atomiques et l’opération trigger-start

Nous protégeons contre les conditions de race liées aux transitions d’état concurrentes entre les opérations PCM atomiques, mais les vérifications entre les opérations non atomiques (hw_params, hw_free et prepare) et les opérations atomiques ne sont pas parfaites ; une vérification de l’état PCM conflictuel est effectuée au début des fonctions hw_params et similaires, mais les opérations PCM atomiques peuvent toujours être émises pendant les opérations PCM non atomiques. Un exemple d’un tel scénario consiste en un thread A qui réémet PREPARE ou HW_PARAMS pour un flux déjà préparé, tandis qu’un autre thread B déclenche le démarrage du PCM au milieu de l’opération prepare. Bien que cela ne conduise généralement pas à des problèmes très graves, cela peut provoquer certaines incohérences telles que rapportées par syzkaller (par exemple, avertissement ODEBUG).

Il existe diverses opérations PCM atomiques, et essentiellement le seul problème concerne le démarrage du PCM car il opère depuis l’état PREPARED. Les autres commandes trigger (stop, etc.) sont destinées à l’état running ou à d’autres états spéciaux ; elles sont donc filtrées comme condition préalable.

Ce correctif vise à empêcher le déclenchement du démarrage du PCM pendant les opérations non atomiques afin de résoudre les problèmes ci-dessus. Heureusement, les opérations hw_params, hw_free et prepare appellent snd_pcm_buffer_access_lock(), ce qui peut être utilisé pour vérifier les opérations concurrentes lors du trigger du PCM – celui-ci définit runtime->buffer_accessing à une valeur négative (si possible), donc le déclenchement du PCM doit simplement vérifier la valeur de runtime->buffer_accessing ; si elle est négative, cela signifie qu’une opération non atomique PCM concurrente est en cours d’exécution.

Once again VulDB remains the best source for vulnerability data.

Responsable

Linux

Réserver

11/09/2026

Divulgation

17/09/2026

Modérer

accepté

Entrée

VDB-405795

CPE

prêt

EPSS

0.00000

KEV

non

Activités

très faible

Sources

Do you need the next level of professionalism?

Upgrade your account now!