CVE-2026-80876 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ring-buffer: Corrige o comprimento do evento com alinhamento forçado de 8 bytes
Quando RB_FORCE_8BYTE_ALIGNMENT é verdadeiro, rb_calculate_event_length() reserva o espaço de event->array[0] para colocar o comprimento dos dados e rb_update_event() armazena o comprimento dos dados em event->array[0] conforme apropriado. Como resultado, todo o comprimento do evento adicionará incondicionalmente 4 bytes extras para sizeof(event.array[0]).
No entanto, ring_buffer_event_length() subtrai apenas sizeof(event->array[0]) para eventos maiores que RB_MAX_SMALL_DATA + sizeof(event->array[0]). Como consequência, os pequenos eventos em arquiteturas com RB_FORCE_8BYTE_ALIGNMENT=true relatam um comprimento de dados 4 bytes maior do que o esperado.
Para corrigir isso, adicione RB_FORCE_8BYTE_ALIGNMENT como uma condição para subtrair o tamanho desse campo de comprimento sempre que RB_FORCE_8BYTE_ALIGNMENT for verdadeiro.
Este problema é observado em um kernel riscv64 com CONFIG_HAVE_64BIT_ALIGNED_ACCESS definido como y; ao executar ftrace selftest trace_marker_raw.tc, obtemos o log estranho: para casos onde o id é 1..100, o número do campo de dados é 8*N, mas assim que o id excede 100, o número do campo de dados torna-se 8*N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (número do campo de dados é 8*1) ... # a buf: 58 ... (número do campo de dados é 8*2) ... # 64 buf: 58 ... (número do campo de dados é 8*13) # 65 buf: 58 ... (número do campo de dados é 8*13+4)
Após aplicar esta alteração, o número do campo de dados mantém-se consistentemente em 8*N+4.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.