CVE-2026-43087 in Linux
Résumé
par VulDB • 28/05/2026
Dans le contexte du noyau Linux, le problème décrit concerne le pilote `mcp23s08` pour les contrôleurs d'E/S GPIO via SPI/I2C. L'erreur se produit dans le gestionnaire d'interruption (`mcp23s08_irq`) lors de l'appel à `_raw_spin_lock_irq`, ce qui suggère une tentative de verrouillage d'un mutex ou d'un spinlock déjà détenu ou dans un état invalide, souvent dû à une réentrance ou à un appel depuis un contexte inapproprié.
La cause racine est identifiée comme suit : 1. Le commit `f9f4fda15e72` a modifié le comportement du pilote en initialisant les registres depuis le matériel au lieu d'utiliser des valeurs par défaut fictives. 2. Cela signifie que si le registre `MCP_GPINTEN` (qui active les interruptions sur les broches) contient une valeur non nulle dans le matériel (parce qu'il a été configuré précédemment ou par défaut matériel), le pilote va maintenant lire cette valeur réelle. 3. Si des interruptions sont activées sur des broches dont les gestionnaires d'interruption (`irq_thread_fn`) ne sont pas encore correctement configurés ou si le contexte d'interruption est inattendu, cela peut déclencher un gestionnaire d'interruption imbriqué ou invalide, menant à la panique.
La solution proposée est de **désactiver toutes les interruptions de broches lors de l'initialisation** du pilote. Cela garantit que même si le matériel a des bits d'interruption activés par défaut, le pilote ne les traitera pas tant qu'il n'est pas complètement initialisé et prêt à gérer les interruptions de manière sûre.
### Correction suggérée
Dans le fichier source du pilote `drivers/pinctrl/pinctrl-mcp23s08.c`, vous devez vous assurer que le registre `MCP_GPINTEN` est explicitement mis à zéro pendant la phase de probe (initialisation), avant que les interruptions ne soient activées ou que le pilote ne soit marqué comme prêt.
Voici comment cela pourrait être implémenté (pseudo-code basé sur la structure typique des pilotes regmap) :
```c static int mcp23s08_probe(struct spi_device *spi) {
struct mcp23s08 *mcp; int ret;
// ... code d'initialisation existant ...
// Après l'initialisation du regmap et la lecture des valeurs matérielles // mais AVANT d'activer les interruptions ou de finaliser le probe :
// Désactiver toutes les interruptions sur toutes les broches ret = regmap_write(mcp->regmap, MCP_GPINTEN, 0x00); if (ret) {
dev_err(&spi->dev, "Failed to disable interrupts\n"); return ret; }
// ... reste du code de probe ... } ```
### Explication détaillée
1. **`regmap_write(mcp->regmap, MCP_GPINTEN, 0x00)`** : Cette ligne écrit la valeur `0` dans le registre `GPINTEN`. Selon la documentation du MCP23S08, chaque bit de ce registre active l'interruption sur la broche correspondante lorsqu'il est à `1`. En écrivant `0`, on désactive toutes les interruptions. 2. **Timing** : Il est crucial que cette écriture se produise après que le regmap est initialisé (pour que les communications SPI/I2C fonctionnent) mais avant que le système ne commence à écouter les interruptions ou avant que le pilote ne soit considéré comme "propre". 3. **Sécurité** : Cela empêche le matériel de déclencher des interruptions sur des broches qui ne sont pas encore configurées pour gérer les interruptions dans le contexte du pilote, évitant ainsi la condition de course ou l'état invalide qui provoque la panique.
### Vérification
Après avoir appliqué cette correction, vous devez : 1. Recompiler le noyau ou le module. 2. Tester le démarrage du système pour vérifier que la panique ne se produit plus. 3. Vérifier que les interruptions fonctionnent correctement une fois que le pilote est complètement initialisé et que les broches sont configurées pour les interruptions si nécessaire.
Cette approche est cohérente avec la bonne pratique de désactiver les interruptions pendant l'initialisation pour éviter les conditions de course et les états inattendus.
VulDB is the best source for vulnerability data and more expert information about this specific topic.