A recent Android WLAN disclosure is a clean case study in third-party component risk — and in what Article 13(5) now asks of every manufacturer placing a connected product on the EU market.
On 10 September 2026 — one day before the Cyber Resilience Act’s first hard deadline took effect — security researcher Denis Laskov circulated a summary of a conference talk on Android WLAN driver security. The talk, “Vulns in Android WLAN for Qualcomm and Samsung: attack surface for QCACLD and SCSC,” walks through a decade of vulnerabilities in the wireless kernel drivers that ship inside a very large share of the world’s Android phones, IoT devices, and connected vehicles.
It is worth reading not because the specific bugs are catastrophic — most of them are not — but because the talk is one of the clearest public illustrations we have seen of the exact risk the CRA’s component-due-diligence obligations were written to address. If a Qualcomm or Samsung WLAN chipset sits inside a product you place on the EU market, the security of that driver is now your compliance problem. Not the silicon vendor’s. Yours.
What the research actually showed
Modern wireless drivers are configured through a Linux kernel interface called cfg80211/nl80211. It is a large, lightly scrutinised attack surface, and it has an awkward property: configuration data arrives as netlink attribute buffers that can be nested — buffers within buffers, several layers deep. Validation has to happen at every level. Miss a check on an inner buffer and the outer validation counts for nothing.
The talk contrasted two vendors:
Qualcomm’s WLAN host driver (QCACLD) consistently uses the kernel’s attribute-policy validation mechanism, which forces length and type checks on incoming data. That discipline makes bugs materially harder to find — though not impossible. The researcher still demonstrated a buffer overflow reachable by sending 256 nested attributes to wrap an 8-bit channel counter back to zero, defeating the bounds check.
Samsung’s Exynos WLAN stack (SCSC) largely omits that policy validation. The result, in the researcher’s words, was closer to “shooting fish in a barrel”: buffer overflows and over-reads in nearly every command handler, including a textbook case where the driver reads a length value out of one attribute and then copies exactly that many bytes with no check at all.
Laskov’s summary distils this to “Qualcomm’s WLAN driver is more secure.” That is a fair headline, but the more precise — and more useful — reading is that Qualcomm’s input-validation discipline is better. It is not a clean bill of health for either vendor, and the researcher was explicit that public advisories undercount the real number of issues.
A note on severity, because credibility matters here: many of the disclosed bugs require local access with elevated capabilities and are not remotely exploitable. The significance is not any single finding. It is the systemic pattern — a shipped, widely deployed component with weak input validation — sitting on an attack surface that has, historically, also produced the remote, zero-click, over-the-air path from a Wi-Fi packet straight to the kernel (the QualPwn class of bugs being the best-known example). That is the tail risk a manufacturer inherits along with the chipset.
Why this lands on the integrator, not the chip vendor
Under the CRA, the manufacturer is the party that places the finished product on the market under its own name or trademark. When that product integrates a component sourced from a third party — and a WLAN chipset plus its driver and firmware is exactly that — Article 13(5) requires the manufacturer to exercise due diligence so the component does not compromise the cybersecurity of the whole product.
The European Commission’s July 2026 guidance is concrete about what that means in practice: determine what your product actually needs from each component to meet its cybersecurity objectives, and then verify, in a risk-based way, that the component satisfies those needs — through technical specifications, the supplier’s security documentation, conformity or assurance evidence, or your own testing. “We use a reputable silicon vendor” is where that analysis begins, not where it ends.
Once the driver is inside your product, it is your product. That pulls in the essential requirements of Annex I, Part I — among them: no known exploitable vulnerabilities at the point of placing on the market, protection against unauthorised access, integrity and confidentiality of data, and minimisation of attack surface. A driver that copies attacker-controlled lengths without bounds checks cuts directly against several of these.
Three further hooks follow:
- Article 13(3) requires your cybersecurity risk assessment, carried into the technical documentation, to reckon with the real attack surface. For a wireless product that means the over-the-air and pre-authentication paths — the radio stack cannot be treated as an opaque black box that belongs to someone else.
- Article 13(6) requires that if you identify a vulnerability in an integrated component, you report it to the entity maintaining the component and remediate it under your own vulnerability-handling obligations (Annex I, Part II).
- Because WLAN is radio equipment, the same driver simultaneously engages the Radio Equipment Directive's Article 3.3 cybersecurity requirements and EN 18031. One component, two regimes — a point worth holding onto if your compliance programme still treats CRA and RED as separate tracks.
The vendor-management lessons are the real payload
Strip away the kernel internals and the talk is, at heart, a supply-chain story. Five lessons transfer directly to how a manufacturer should manage a silicon or module supplier under the CRA.
“Patched” is not the same as “fixed.” One of the more damning moments in the talk was a Samsung patch that added a length check — against a completely unrelated attribute. It compiled, it closed the ticket, and it changed nothing; the overflow was still reachable. A vendor bulletin line saying a CVE is “addressed” is a claim, not evidence. Your due diligence has to confirm the fix actually lands in your build and actually remediates the issue.
Security bulletins are a floor, not a ceiling. The researcher was candid that internal issues often go unpublished and that public advisories understate the true count. Vulnerability monitoring that depends solely on a supplier’s bulletin feed will systematically miss things.
Your supplier’s org chart is part of your risk surface. Reports fell through the gap between two different Samsung security teams — mobile and semiconductor — that, by his account, don’t share responsibility for the same code. When you integrate a component, you need to know precisely who owns security for that exact part, how they coordinate, and where the seams are.
Supplier maturity is assessable — that’s what risk-based verification is for. The Qualcomm-versus-Samsung contrast is not a matter of taste. “Does this vendor enforce input-validation policy on its driver’s configuration interface?” is a concrete, checkable engineering-hygiene question, and precisely the kind of signal a competent Article 13(5) assessment should surface before you commit a component to a product.
Ease of discovery implies adversary parity. A single researcher, working in spare time, found dozens of these issues. It is prudent to assume that capable adversaries — who do this full-time — have found them too, or can.
What a manufacturer should actually do
If you ship a connected product with a Qualcomm or Samsung WLAN component inside, a defensible CRA posture looks like this:
- Inventory it. The WLAN host driver and its firmware should appear in your SBOM, named at the version level. Component-level visibility is the prerequisite for everything downstream, including reporting readiness.
- Assess the right surface. Your risk assessment should explicitly cover the over-the-air and pre-authentication paths, not only the application layer.
- Hold evidence, not assumptions. Document what you have actually verified about the component's security, and retain the supplier's security documentation and conformity or assurance evidence to back it.
- Get it in the contract. Security-update SLAs and coordinated-disclosure commitments from the silicon vendor, aligned to the CRA support period you have declared. If the vendor stops patching before your support period ends, that gap is yours to close.
- Verify remediation. Confirm that upstream fixes reach your build and genuinely resolve the underlying flaw — the wrong-attribute patch above is exactly the failure mode to guard against.
- Stand up the reporting pipeline. As of 11 September 2026, Article 14's reporting obligations are live. If a vulnerability in your product is actively exploited, you are on the clock: an early warning within 24 hours, a fuller notification within 72, and a final report within 14 days of a fix, submitted through the ENISA Single Reporting Platform.
The takeaway
“We use a major vendor’s chipset” is the opening line of a due-diligence exercise, not a substitute for one. The CRA makes the integrator responsible for the security of the whole product — including the parts it bought rather than built — and it now expects that responsibility to be evidenced, not asserted.
Turning “the driver is somebody else’s code” into defensible Article 13(5) evidence, an accurate risk assessment, and a reporting process that will hold up under scrutiny is the work. It is the work Kokobo does with manufacturers navigating the CRA and RED together. If a wireless component sits inside a product you sell into the EU, we can help you show that you have done the diligence the regulation now requires.
Kokobo LLC advises device manufacturers on EU Cyber Resilience Act and Radio Equipment Directive / EN 18031 cybersecurity compliance.