CVE-2026-80876 in Linux
Riassunto
di VulDB • 04/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ring-buffer: Correzione della lunghezza dell'evento con allineamento forzato a 8 byte
Quando RB_FORCE_8BYTE_ALIGNMENT è true, rb_calculate_event_length() riserva lo spazio di event->array[0] per inserire la lunghezza dei dati e rb_update_event() memorizza la lunghezza dei dati in event->array[0] di conseguenza. Di conseguenza, l'intera lunghezza dell'evento aggiunge incondizionatamente 4 byte extra per sizeof(event.array[0]).
Tuttavia, ring_buffer_event_length() sottrae solo sizeof(event->array[0]) per gli eventi più grandi di RB_MAX_SMALL_DATA + sizeof(event->array[0]). Di conseguenza, gli eventi piccoli su architetture con RB_FORCE_8BYTE_ALIGNMENT=true riportano una lunghezza dei dati pari a 4 byte in più rispetto al previsto.
Per risolvere il problema, aggiungere RB_FORCE_8BYTE_ALIGNMENT come condizione per sottrarre la dimensione di tale campo della lunghezza ogni volta che RB_FORCE_8BYTE_ALIGNMENT è true.
Questo problema si osserva in un kernel riscv64 con CONFIG_HAVE_64BIT_ALIGNED_ACCESS impostato a y; quando eseguiamo il test selftest ftrace trace_marker_raw.tc, otteniamo un log anomalo: nei casi in cui l'id sia da 1 a 100, il numero di campi dati è 8*N, ma una volta che l'id supera 100, il numero di campi dati diventa 8*N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (il numero di campi dati è 8*1) ... # a buf: 58 ... (il numero di campi dati è 8*2) ... # 64 buf: 58 ... (il numero di campi dati è 8*13) # 65 buf: 58 ... (il numero di campi dati è 8*13+4)
Dopo aver applicato questa modifica, il numero di campi dati rimane costantemente pari a 8*N+4.
If you want to get best quality of vulnerability data, you may have to visit VulDB.