CVE-2022-50401 in Linux
Résumé
par VulDB • 21/05/2026
Dans le noyau Linux, une erreur `list_add corruption` indique que la structure de données `list_head` a été corrompue. Cela se produit généralement lorsque :
1. **Une liste doublement chaînée est modifiée de manière incorrecte** (par exemple, ajout/suppression sans verrouillage approprié). 2. **Une mémoire est libérée prématurément** ou réutilisée pendant qu’elle est encore référencée dans une liste. 3. **Une opération de liste est effectuée sur une liste déjà corrompue** (par exemple, `next->prev` ne pointe pas vers `prev` comme attendu).
### Analyse de la trace
La trace montre que la corruption a été détectée dans le contexte du sous-système **NFS** (`nfsd`), plus précisément lors du traitement d’une mise à jour de callback (`nfsd4_process_cb_update`).
#### Points clés : - **Fonction responsable** : `nfsd4_process_cb_update.isra.11` - **Contexte** : Travail asynchrone (`nfsd4_run_cb_work`) exécuté par un thread de travail (`worker_thread`). - **Erreur spécifique** : `next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018`.
Cela signifie que lors de l’ajout d’un élément à une liste, la valeur attendue de `next->prev` (qui devrait pointer vers l’élément précédent dans la liste) ne correspond pas à la réalité. L’élément `next` pointe vers une adresse (`ffff89ac4763e018`) qui n’est pas celle attendue (`ffff89ac4977e538`).
### Causes possibles
1. **Race condition** : - Plusieurs threads modifient la même liste sans synchronisation adéquate. - Dans le contexte NFS, cela pourrait se produire si plusieurs callbacks sont traités simultanément et accèdent à des structures partagées.
2. **Utilisation après libération (Use-After-Free)** : - Une structure `list_head` a été libérée (`kfree` ou similaire) mais est toujours référencée dans une liste. - Si la mémoire est réallouée pour une autre structure, les pointeurs `next` et `prev` peuvent devenir invalides.
3. **Corruption de mémoire** : - Une écriture hors limites (buffer overflow) a corrompu les pointeurs `next` et `prev` d’une structure `list_head`.
4. **Bug dans le code NFS** : - Une erreur de programmation dans `nfsd4_process_cb_update` ou une fonction appelée depuis celle-ci.
### Étapes de diagnostic
1. **Vérifier les logs précédents** : - Recherchez des messages de `BUG: unable to handle kernel paging request`, `slab corruption`, ou `memory leak` avant cette erreur.
2. **Analyser les structures impliquées** : - Identifiez la liste corrompue. Dans le code NFS, cela pourrait être une liste de callbacks en attente ou une liste de clients. - Utilisez `debugfs` ou `kdump` pour examiner les structures mémoire au moment de l’erreur.
3. **Reproduire le problème** : - Si possible, reproduisez la charge NFS qui déclenche l’erreur. - Activez les options de débogage du noyau : ```bash echo 1 > /sys/kernel/debug/nfsd/nfsd_debug ```
4. **Vérifier les patches récents** : - Ce bug a-t-il été signalé dans les versions récentes du noyau ? - Consultez les rapports de bugs sur [kernel.org](https://bugzilla.kernel.org/) ou [LWN.net](https://lwn.net/).
5. **Mettre à jour le noyau** : - Si ce bug est connu, une mise à jour vers une version plus récente du noyau peut le corriger.
### Solution temporaire
Si vous ne pouvez pas mettre à jour le noyau immédiatement, vous pouvez essayer de :
1. **Réduire la charge NFS** : - Limitez le nombre de clients NFS ou le nombre de callbacks simultanés.
2. **Désactiver les callbacks NFS** : - Si les callbacks ne sont pas essentiels, vous pouvez les désactiver dans la configuration NFS.
3. **Activer les protections de mémoire** : - Activez `CONFIG_DEBUG_LIST` dans la
If you want to get best quality of vulnerability data, you may have to visit VulDB.