libpcap 1.10.7: patch CVE-2026-31912 nie działa bez migracji z `bpf_filter()` — kiedy fixed library version nadal zostawia podatny execution path

9 września 2026 maintainer libpcap podsumował siedem podatności naprawionych w 1.10.7. Najważniejsze zdanie nie brzmi „zaktualizuj bibliotekę”: dla CVE-2026-31912 aplikacje używające zdeprecjonowanego bpf_filter() muszą zostać zmigrowane do pcap_offline_filter(), aby poprawka była skuteczna. To zmienia typowy model remediation.

1.10.7 zamyka 7 CVE: m.in. CVE-2026-0799 (brak walidacji scratch memory register → R/W pamięci procesu), CVE-2026-31912 (interpreter nie wykrywa końca programu bez return/skoku poza bufor), CVE-2026-6244 (dzielenie przez zero), CVE-2026-6554 (nieograniczone backward jumps → pętla), CVE-2026-18313/18238 (rpcapd/klient rpcap).

Haczyk 31912: sam upgrade nie wystarcza aplikacji nadal wołającej bpf_filter().

libpcap upgraded to 1.10.7 → czy aplikacja nadal wywołuje bpf_filter()? TAK → remediation niepełna dla CVE-2026-31912 NIE → przejdź do runtime verification

package state = fixed, application state = potentially vulnerable

To jedna z najgroźniejszych klas false closure — dashboard „zielony”: scanner widzi libpcap 1.10.7, CMDB „patch deployed”, ale nikt nie sprawdził symbolu/API. Wykrywanie: source-level (grep -R "bpf_filter(" .), binary-level (nm -D binary | grep bpf_filter, objdump -T), runtime tracing dla krytycznych. Brak symbolu jest silniejszym evidence niż numer pakietu.

SBOM pokaże wersję, nie consuming API

SBOM: component: libpcap, version: 1.10.7 — ale nie consuming API: bpf_filter(). Potrzebny funkcjonalny reachability graph (application uses libpcap::bpf_filter), nie tylko dependency graph. VEX per-API: zmigrowana → not_affected / vulnerable_api_not_used; 1.10.7 ale nadal bpf_filter() → affected / vulnerable_execution_path_present; nieznane → under_investigation.

Build flags zmieniają attack surface

Maintainer ostrzega, że remote packet capture jest eksperymentalne i niebezpieczne dla produkcji/untrusted, a non-default build może przypadkiem włączyć rpcap. Ponieważ CVE-2026-18313 dotyczy rpcapd, a 18238 klienta — build provenance staje się częścią exploitability: same source version + different build flags = different network exposure. VM powinien zbierać, czy rpcap jest skompilowany, czy rpcapd działa i czy listener jest osiągalny.

Dwie kampanie i weryfikacja

Rozdziel: infrastructure/package campaign (upgrade libpcap ≥ 1.10.7) i application migration campaign (znajdź konsumentów bpf_filter() → migruj → rebuild/redeploy → verify symbol/runtime). Checklist: runtime ≥ 1.10.7, aplikacja przebudowana, brak bpf_filter(), brak starego procesu z pre-upgrade mapping (upgrade .so na dysku nie zmienia kodu zmapowanego do pamięci), rpcap build flag sprawdzony.

Wniosek

libpcap 1.10.7 pokazuje trzy poziomy prawdy: source fixed → package updated → application actually remediated — nie zawsze te same momenty. Zapytaj swój scanner: czy host z 1.10.7 i aplikacją nadal używającą bpf_filter() pokażesz jako fixed? Jeśli tak, śledzi pakiet, nie security property.

Powiązane na blogu

libfuse: build vs runtime — remediation zależna od buildu i runtime
h3: dane a rzeczywistość — kontrakt narzędzia vs oczekiwanie

Źródła

libpcap / oss-security — „libpcap 1.10.7 fixes 7 vulnerabilities” (09.09.2026) — seclists.org

Nota redakcyjna: stan informacji 9 września 2026. libpcap 1.10.7 zamyka 7 CVE; dla CVE-2026-31912 maintainer wymaga migracji z bpf_filter() do pcap_offline_filter(), inaczej poprawka jest nieskuteczna. Artykuł koncentruje się na remediation dependency poza komponentem i na build flags (rpcap) zmieniających attack surface.