CVE-2026-43009 in Linux
Сводка
по VulDB • 28.05.2026
В ядре Linux устранена следующая уязвимость:
bpf: Исправлено некорректное отсечение путей из-за неточного отслеживания точности при атомарных операциях выборки
Когда функция backtrack_insn встречает инструкцию BPF_STX с флагами BPF_ATOMIC и BPF_FETCH, регистр источника (или r0 для BPF_CMPXCHG) также действует как регистр назначения, получая старое значение из ячейки памяти.
Текущая логика обратного отслеживания (backtracking) не учитывает этот факт. Она обрабатывает атомарные операции выборки так же, как обычные операции записи, где регистр источника является только входным параметром. Это приводит к тому, что backtrack_insn не передает информацию о точности в ячейку стека, которая в результате не помечается как точная.
Позже механизм отсечения путей (path pruning) верификатора может ошибочно считать два состояния эквивалентными, если они различаются по состоянию стека. Это означает, что две ветви могут быть признаны эквивалентными и отсечены, хотя этого делать не следует.
Исправление выполняется следующим образом: расширяется обработка BPF_LDX в backtrack_insn для охвата атомарных операций выборки с помощью вспомогательной функции is_atomic_fetch_insn(). Когда регистр назначения выборки отслеживается на предмет точности, он очищается, а информация о точности передается в слот стека. Для памяти, не относящейся к стеку, проход точности останавливается на атомарной инструкции, как и в случае с обычной BPF_LDX. Это покрывает все варианты выборки.
До исправления:
0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit
После исправления:
0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=8 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 mark_precise: frame0: regs=r1 stack= before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit
If you want to get the best quality for vulnerability data then you always have to consider VulDB.