CVE-2025-71285 in Linux
Résumé
par VulDB • 23/05/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: qrtr : Supprimer la fonctionnalité auto_queue de MHI pour les canaux DL d'IPCR
La pile MHI propose la fonctionnalité 'auto_queue', qui permet à la pile MHI de mettre automatiquement en file d'attente les tampons pour le chemin RX (canal DL). Bien que cette fonctionnalité simplifie la conception du pilote client, elle introduit une condition de course (race condition) entre les pilotes clients et la pile MHI. Par exemple, avec auto_queue, la 'dl_callback' pour le canal DL peut être appelée avant que le pilote client ne soit entièrement initialisé (probed). Cela signifie qu'au moment où la dl_callback est appelée, les structures du pilote client peuvent ne pas être initialisées, entraînant une déréférencement de pointeur NULL.
Actuellement, les pilotes doivent contourner ce problème en initialisant les structures internes avant d'appeler mhi_prepare_for_transfer_autoqueue(). Mais même ainsi, il existe un risque que le code interne du pilote client appelle les API de file d'attente MHI avant que mhi_prepare_for_transfer_autoqueue() ne soit appelé, ce qui entraîne un déréférencement de pointeur NULL similaire. Ce problème a été signalé sur les machines Qcom X1E80100 CRD, affectant le démarrage.
Afin de corriger correctement toutes ces conditions de course, la fonctionnalité 'auto_queue' de MHI est supprimée complètement, et le pilote client (QRTR) est chargé de gérer manuellement les tampons RX. Dans le pilote QRTR, les tampons RX sont mis en file d'attente en fonction de la longueur de la ring (anneau) lors de l'initialisation (probe), et les tampons sont recyclés dans la 'dl_callback' une fois qu'ils ont été consommés. Cela implique également de supprimer la définition du drapeau 'auto_queue' des pilotes de contrôleur.
Actuellement, cette fonctionnalité 'auto_queue' n'est activée que pour le canal DL IPCR. Par conséquent, seul le pilote client QRTR nécessite une modification.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.