Lifecycle Timeline
4Description
In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present.
Analysis
A use-of-uninitialized-variable vulnerability exists in the Linux kernel's radiotap parser that can lead to information disclosure when processing radiotap frames with undefined fields. The vulnerability affects all Linux kernel versions using the radiotap namespace parser (cpe:2.3:a:linux:linux) and occurs when undefined radiotap field 18 is present, causing the iterator->_next_ns_data variable to be compared against an uninitialized value. …
Sign in for full analysis, threat intelligence, and remediation guidance.
Priority Score
Vendor Status
Debian
| Release | Status | Fixed Version | Urgency |
|---|---|---|---|
| bullseye | vulnerable | 5.10.223-1 | - |
| bullseye (security) | vulnerable | 5.10.251-1 | - |
| bookworm | vulnerable | 6.1.159-1 | - |
| bookworm (security) | vulnerable | 6.1.164-1 | - |
| trixie | vulnerable | 6.12.73-1 | - |
| trixie (security) | vulnerable | 6.12.74-2 | - |
| forky, sid | fixed | 6.19.8-1 | - |
| (unstable) | fixed | 6.19.8-1 | - |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-15350
GHSA-mg4x-3g76-43w7