fix: down-rank unbounded-range CVE matches on vendor-fork components - #30
Merged
Merged
Conversation
A binary version banner like "hostapd v0.8.x_rtw_r24647.20171025" is a vendor
SDK fork (here Realtek's "_rtw_" hostapd, ubiquitous on IoT Wi-Fi SoCs). The
version was stripped to a base semver ("0.8") for matching, and the NVD CPE
range for CVEs such as CVE-2022-23303/23304 (SAE side-channels) has no lower
bound, so "0.8 < 2.10" matched them as high-signal even though SAE did not exist
until hostapd 2.x -- the fork's base cannot contain the vulnerable code.
Two changes:
- binary-version detection now records the vendor-fork label (Component::fork)
when the version tail continued past the base semver with a non-numeric tag,
and keeps the full on-disk banner in the evidence instead of the truncated
base (so the fork/revision is not lost).
- the CVE join flags matches from an unbounded-below range and, on a fork
component, drops them from the default high-signal view (KEV still overrides),
annotating the basis "... lower-bound unknown -- verify". Such matches remain
in the full list under --component-cves-all.
This demotes the uncertain fork matches without asserting (in)applicability; a
bounded-range CVE that genuinely covers the base version is unaffected. Add unit
coverage for the fork label/evidence and the gate (fork+unbounded demoted,
either flag alone kept, KEV overrides).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Vendor SDK forks of hostapd/wpa_supplicant carry version banners like
hostapd v0.8.x_rtw_r24647.20171025(Realtek's_rtw_fork — very common on IoT Wi-Fi SoCs; AltoBeam's_ATBMis another). The binary-version detector strips these to a base semver (0.8) for matching, and many NVD CPE ranges have no lower bound, so0.8 < 2.10matches CVEs like CVE-2022-23303/23304 (SAE/EAP-pwd side-channels) as high-signal — even though the vulnerable feature (SAE) did not exist until hostapd 2.x, so a 0.8-based fork cannot contain the code. The result is confident, top-of-list false positives.Change
Two parts:
Fork detection + version fidelity (
binary-version). After parsing the base semver, the detector inspects the tail that continued past it. A non-numeric tail (_rtw_,_ATBM,-devel, …) records aComponent::forklabel ("Realtek SDK"/"AltoBeam SDK"/"vendor fork") and keeps the full on-disk banner in the evidence, instead of the truncated base version.CVE-join demotion. A match from an unbounded-below range (no exact version and no start bound) on a fork component is dropped from the default high-signal view, with the basis annotated
[<fork>; range lower-bound unknown -- verify]. KEV still overrides. The match stays in the full list under--component-cves-all.This demotes uncertain fork matches without asserting (in)applicability — the honesty bar. A bounded-range CVE that genuinely covers the base version is unaffected, and a non-fork component is unaffected.
Scope / limitation
This is a heuristic down-rank, not proof. The more precise follow-up (tracked separately) is symbol/feature-presence gating — the userspace analog of the kernel's config-gated CVE checklist — which would confirm the vulnerable code is actually present in the binary.
Tests
Unit coverage for the fork label + full-banner evidence, and for the gate: fork + unbounded-below is demoted; either flag alone is kept; KEV overrides. Full unit suite (1406 checks) and integration suite pass; clean under ASan+UBSan.