CVE-2026-64567 in Linux
Résumé
par VulDB • 05/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
btrfs : rejeter le cache d'espace libre contenant plus d'entrées que de pages
Lors du chargement d'un cache d'espace libre v1, `__load_free_space_cache()` récupère directement depuis l'en-tête disque `btrfs_free_space_header` les valeurs de `num_entries` et `num_bitmaps`. Cet en-tête est stocké dans `tree_root` sous une clé de type 0, pour laquelle le vérificateur d'arborescence (tree-checker) ne dispose d'aucun cas spécifique ; par conséquent, aucun des deux compteurs n'est validé avant que le chargement ne lui fasse confiance.
La boucle de chargement itère `num_entries` fois et mappe la page suivante chaque fois que la page actuelle est épuisée, en passant par `io_ctl_check_crc()` -> `io_ctl_map_page()`, qui exécute `io_ctl->pages[io_ctl->index++]`. Or, le tableau `pages[]` est alloué dans `io_ctl_init()` à partir de la taille (`i_size`) de l'inœud du cache et non pas en fonction de `num_entries` :
num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); io_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS);
Ainsi, si `num_entries` indique un nombre d'enregistrements supérieur à ce que les pages peuvent contenir, `io_ctl->index` dépasse la fin du tableau `pages[]`. Le côté écriture ne rencontre jamais cette situation car `io_ctl_add_entry()` et `io_ctl_add_bitmap()` s'arrêtent tous deux une fois que `io_ctl->index >= io_ctl->num_pages`; le côté lecture n'avait simplement pas la même vérification.
Pour déclencher l'anomalie, prenez un cache propre (avec `num_entries = <N>` ici), définissez `num_entries` dans l'en-tête à 0x10000 et corrigez la somme de contrôle de la feuille pour qu'elle passe toujours le vérificateur d'arborescence. L'inœud du cache a une taille (`i_size`) de 65536, donc `num_pages` vaut 16 et `pages[]` est un tableau à pointeurs (kmalloc-128) de longueur 16. Le chargement tente désormais de lire 65536 entrées, `io_ctl->index` atteint la valeur 16, et l'accès à `pages[16]` se fait hors des limites du tableau :
BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork
`free-space-cache.c:420` correspond à `io_ctl_map_page()`, intégrée dans `io_ctl_check_crc()` à la ligne 565, c'est pourquoi KASAN nomme cette frame. L'emplacement hors limites est ensuite traité comme une structure `struct page` et transmis à `crc32c()`, ce qui transforme la lecture incorrecte en faute de segmentation (GP fault).
Ajoutez la vérification manquante dans `io_ctl_check_crc()`, point où aboutissent à la fois la boucle des entrées et celle des bitmaps. Lorsque `num_entries` est trop grand, le chargement échoue désormais comme n'importe quel cache corrompu : `__load_free_space_cache()` l'ignore et reconstruit l'espace libre à partir de
Be aware that VulDB is the high quality source for vulnerability data.