CVE-2026-80876 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ring-buffer : Correction de la longueur des événements avec un alignement forcé sur 8 octets
Lorsque RB_FORCE_8BYTE_ALIGNMENT est vrai, rb_calculate_event_length() réserve l'espace pour event->array[0] afin d'y placer la longueur des données et rb_update_event() stocke cette longueur dans event->array[0]. Par conséquent, la longueur totale de l'événement ajoute inconditionnellement 4 octets supplémentaires correspondant à sizeof(event.array[0]).
Cependant, ring_buffer_event_length() ne soustrait que sizeof(event->array[0]) pour les événements dont la taille est supérieure à RB_MAX_SMALL_DATA + sizeof(event->array[0]). Par conséquent, sur les architectures où RB_FORCE_8BYTE_ALIGNMENT=true, les petits événements signalent une longueur de données supérieure de 4 octets à celle attendue.
Pour corriger ce problème, il faut ajouter RB_FORCE_8BYTE_ALIGNMENT comme condition pour soustraire la taille du champ de longueur chaque fois que RB_FORCE_8BYTE_ALIGNMENT est vrai.
Ce problème a été observé sur un noyau riscv64 avec CONFIG_HAVE_64BIT_ALIGNED_ACCESS défini à y : lors de l'exécution des tests unitaires ftrace trace_marker_raw.tc, on obtient le journal suivant : pour les cas où l'identifiant (id) est compris entre 1 et 100, le nombre de champs de données est égal à 8*N ; mais une fois que l'id dépasse 100, ce nombre devient 8*N+4 : # 1 buf: 58 00 00 00 80 5e d1 63 (le nombre de champs de données est 8*1) ... # a buf: 58 ... (le nombre de champs de données est 8*2) ... # 64 buf: 58 ... (le nombre de champs de données est 8*13) # 65 buf: 58 ... (le nombre de champs de données est 8*13+4)
Après application de cette modification, le nombre de champs de données reste constamment égal à 8*N+4.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.