This CVE is an off-by-one bounds check failure in batman-adv's multicast packet tracking code. The bug: a check uses offsetof() instead of offsetofend() on the first field of a struct, which returns 0 instead of the field size, completely defeating the bounds validation. The check looks correct because it compares something against a buffer length, but that something is always 0 when the field in question is the struct's first member.
This is a structural API design failure, not a developer lapse. The kernel exposes developers to two similarly-named macros whose semantics differ by exactly the size of the field being accessed—a distinction that's nearly impossible to hold in working memory during fast coding or review. The developer likely copied a bounds-check pattern from adjacent code, adapted it mechanically, and neither they nor their reviewer caught the semantic swap because the code compiles, the variable names make sense, and the pattern appears correct.
The vulnerability is an off-by-one READ, not a write. The practical severity depends on what data sits adjacent to the accessed field in the skb layout. If heap pointers or state flags follow the field, you've got potential KASLR bypass or controlled information leaks. If the adjacent data is mostly zeros, practical exploitability is limited. The data being leaked is multicast traversal state—potentially revealing mesh topology and peer relationships to an on-path attacker who crafts malformed multicast packets.
The commit history matters: determining whether this check was added as defensive hardening (making the code silently worse than having no check at all) versus code that was always vulnerable tells you the actual window of exposure. But the deeper failure is that this exact macro swap has appeared in prior kernel vulnerabilities. The kernel's own mailing list archives have documented this failure mode, yet no systemic tooling or process change followed. That's an organizational memory failure no amount of individual developer care can solve.
Post-disclosure, the CVE score obscures more than it reveals. This lives in batman-adv—a module deployed selectively, in a non-default feature, in a peripheral mesh overlay protocol. Enterprise distros will patch quickly, but embedded and custom builds won't see updates for months. The disclosure event itself is now a risk multiplier: every passive scanner and IDS signature developer will add this to their rules within days. The window for quiet exploitation closes, but the window for targeted exploitation of unpatched systems opens. Prioritize patching if you deploy batman-adv multicast handling; treat any unpatched暴露 in production as an information disclosure risk with potential topology leakage implications.