Skip to content
AESTECHNO
23 min read Hugues Orgitello EN

Cyber Resilience Act for embedded Linux: CVE-2026-53362

Cyber Resilience Act for embedded Linux: CVE-2026-53362 is exploited and 6.1/6.6 LTS ship it. AESTECHNO in Montpellier on the 24-hour reporting clock.
The same kernel vulnerability seen from an enterprise server and from an embedded product Two columns compared. On the left, the enterprise view of CVE-2026-53362: a container escape, mitigated by disabling unprivileged user namespaces, fixed by a distribution update. On the right, the embedded view: no containers at all, so the published mitigation changes nothing, the kernel comes from a frozen vendor board support package, and from 11 September 2026 the Cyber Resilience Act adds a 24 hour reporting duty. CVE-2026-53362: same bug, two very different problems The advice written for servers does not transfer to a shipped product Enterprise server Threat framing: container escape unprivileged user namespace to host root Mitigation: max_user_namespaces = 0 reduces the attack surface Fix: apt or dnf update, then reboot the distribution ships the kernel Closed in a maintenance window operational problem, solved operationally This is the framing in every advisory you will read about this CVE. Embedded product in the field Threat framing: no containers at all any local process with a UDPv6 socket Mitigation: changes nothing here it guards a feature you never use Fix: backport into a frozen BSP then requalify and ship an update Plus a 24 hour reporting duty CRA Article 14, from 11 September 2026 This is the framing nobody publishes, and the one that decides your exposure. Sources: NVD, CISA KEV catalogue (27 August 2026), Regulation (EU) 2024/2847
CVE-2026-53362 read two ways. The enterprise mitigation that every advisory repeats has no effect on a device that never ran a container.

Every write-up of CVE-2026-53362 gives the same mitigation: disable unprivileged user namespaces. It does nothing for your product, because there are no containers on an embedded Linux device and the flaw stays reachable from any local process holding a UDPv6 socket. That gap between enterprise advice and embedded reality is what the Cyber Resilience Act turns into a legal problem on 11 September 2026.

In this article

What CVE-2026-53362 actually is

CVE-2026-53362 is an out-of-bounds write in the Linux kernel IPv6 fragmentation path, rated 7.8 High by the National Vulnerability Database (NVD). It carries the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, is classified CWE-787 and CWE-122, and reached the CISA catalogue of exploited flaws on 27 August 2026.

The defect sits in __ip6_append_data(). On the paged allocation branch, taken under MSG_MORE, NETIF_F_SG or a large fragment length, the kernel computes alloclen = fragheaderlen + transhdrlen and pagedlen = datalen - transhdrlen. But datalen already includes fraggap, the bytes carried over from the previous socket buffer. The linear area ends up undersized by exactly fraggap bytes while pagedlen is overstated by the same amount, so the copy runs past skb->end into the trailing skb_shared_info.

How an unprivileged process reaches the flaw

An unprivileged user reaches it through a UDPv6 socket combining MSG_MORE with MSG_SPLICE_PAGES. No root, no capability, no special hardware. IPv6 fragmentation itself is specified in RFC 8200, and nothing in the protocol is at fault here: this is an arithmetic error in one implementation of it.

The history matters for anyone auditing an older tree. According to Linux kernel maintainers, the bad accounting arrived with commit 773ba4fe9104, but a second change, ce650a166335, is what made it reachable. Before that commit the negative copy length simply returned -EINVAL. Afterwards the same path was allowed to proceed, and a rejected request became memory corruption. A tree carrying the first commit but not the second is affected on paper and far harder to exploit in practice, which is a distinction worth recording in your analysis rather than discovering during an audit.

How the undersized linear area lets the copy overwrite skb_shared_info Two socket buffer layouts. The correct layout allocates room for the fragment headers plus the carried-over fraggap bytes, so the copy stops before skb_shared_info. The buggy layout omits fraggap from alloclen, so the linear area is too short and the copy continues past the end of the buffer into the skb_shared_info structure that follows it. One missing term, one overwritten structure datalen already contains fraggap, alloclen did not Correct allocation fragment headers fragheaderlen fraggap bytes carried over paged data skb_shared_info untouched OK Allocation before the fix fragment headers fragheaderlen never allocated fraggap missing paged data skb_shared_info overwritten LPE the copy keeps going past skb->end Trigger: an unprivileged UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES Result: arbitrary kernel read and write, then privilege escalation
The fix adds fraggap back into alloclen and subtracts it from pagedlen. Everything the attacker gains comes from that one omitted term.

Why the published mitigation does nothing on embedded Linux

The published mitigation is a sysctl setting that blocks unprivileged user namespaces, which closes the container escape route but leaves the kernel defect entirely untouched. On a product that never creates a container, it protects a feature the device does not use while the vulnerable code path stays open.

The reasoning behind the advisory is sound for its own audience. According to Red Hat, whose bulletin names the issue ipv6_frag_escape, an attacker inside a container creates a network namespace, triggers the overflow, escapes to the host, bypasses SELinux and reaches root. Remove the ability to create namespaces and that specific chain breaks. Enterprise fleets run containers, so the guidance buys real time there, and the accompanying warning that it breaks rootless Podman tells you exactly which audience it was written for.

The threat model on a device with no containers

Your gateway does not run rootless Podman. It runs a handful of daemons under non-root service accounts, and any one of them can open a UDPv6 socket. Compromise a web interface, an MQTT bridge or a field-bus daemon, and the same overflow sits one syscall sequence away from kernel memory. Contrary to the common assumption that a device without containers is out of scope, removing namespaces removes nothing here.

This is where the copying goes wrong. An advisory written for one deployment model gets republished as universal guidance, a manufacturer reads it, applies the sysctl and records the exposure as closed. It is not closed. The same pattern shaped the coverage of the Copy Fail kernel privilege escalation and its Docker escape, where the container framing likewise crowded out every other deployment. Threat modelling that starts from your own architecture instead of someone else's is the habit that prevents it, and it is the same discipline we describe in securing an IoT product from hardware to field deployment.

Which kernel versions are affected, and which ship in products

The affected range is the set of stable branches from 6.0 onward, each one vulnerable until a specific point release carries the fix. Every branch below its fixed release contains the flaw, and the boundary is exact rather than gradual.

That list matters more than it first appears, because two of those branches are the long-term kernels silicon vendors pin their Board Support Package (BSP) to. A product built around an i.MX, STM32MP, AM62 or comparable part is very often running 6.1 or 6.6, which is precisely where the defect lives. Choosing between those branches at design time is covered in our guide to picking an embedded Linux distribution against five criteria, and the same trade-off shapes the choice between Zephyr, FreeRTOS and real-time Linux.

Stable branchFixed inVulnerable belowTypical embedded exposure
6.1 LTS6.1.1776.0 to 6.1.176Very high, the default BSP branch on many SoC families
6.6 LTS6.6.1446.2 to 6.6.143Very high, current generation vendor BSPs
6.12 LTS6.12.956.7 to 6.12.94Moderate, newer designs and mainline-tracking builds
6.18 LTS6.18.386.13 to 6.18.37Rising, the newest LTS and the usual target for a migration today
7.17.1.36.19 to 7.1.2Low, development and desktop targets

Read the middle column as a hard boundary. A kernel reporting 6.1.176 is vulnerable, 6.1.177 is not, and there is no partial state in between. The six stable commits that carry the fix are published on git.kernel.org, one per maintained branch.

Two practical traps follow. A vendor BSP often reports a marketing version that does not match the upstream base, so a board advertised as running "kernel 6.6" may sit anywhere inside that branch. And a long-lived product line frequently ships more than one kernel across its revisions, which means a single answer for the product is usually the wrong answer for the fleet.

Fixed point release for each affected Linux stable branch Five stable kernel branches with the release that carries the fix for CVE-2026-53362. Branch 6.1 is fixed in 6.1.177, branch 6.6 in 6.6.144, branch 6.12 in 6.12.95, branch 6.18 in 6.18.38 and branch 7.1 in 7.1.3. The 6.1 and 6.6 branches are marked as the ones vendor board support packages most often pin to. Where the fix landed, branch by branch Below the marked release the product is vulnerable, at or above it is not Branch Fixed release How often it ships inside a product 6.1 LTS 6.1.177 Very high, the default BSP branch on many SoC families 6.6 LTS 6.6.144 Very high, current generation vendor BSPs 6.12 LTS 6.12.95 Moderate, newer designs and mainline-tracking builds 6.18 LTS 6.18.38 Rising, the newest LTS and usual migration target 7.1 7.1.3 Low, development and desktop targets
Version data from the Linux kernel CNA record for CVE-2026-53362. The two red rows are the branches most likely to be inside a shipped product.

What the Cyber Resilience Act requires from 11 September 2026

The Cyber Resilience Act (CRA) is the European regulation, formally Regulation (EU) 2024/2847, that makes vulnerability reporting mandatory for every product with digital elements sold in the Union. Its reporting obligations become binding on 11 September 2026, fifteen months before the rest of the text applies.

From that date a manufacturer must file an early warning within 24 hours of learning that a vulnerability in its product is being actively exploited, then a fuller notification within 72 hours. Severe incidents follow the same two-stage pattern. Filings go through the Single Reporting Platform (SRP), which routes to the national CSIRT and to ENISA rather than to each member state separately.

CVE-2026-53362 is the textbook trigger. According to CISA, which added it to the Known Exploited Vulnerabilities (KEV) catalogue on 27 August 2026, the flaw is being exploited in the wild, and that is exactly the condition the regulation names. A manufacturer still shipping an unfixed 6.1 or 6.6 kernel after 11 September holds a reportable vulnerability rather than a backlog item.

The grandfathering trap in Article 69(3)

The trap is Article 69(3). Products placed on the market before 11 December 2027 escape the full technical requirements unless substantially modified, and that is the part most manufacturers remember. The derogation does not extend to Article 14: the reporting obligations apply to all in-scope products already on the market. Being grandfathered protects your technical file, not your reporting duty. Our full Cyber Resilience Act compliance guide for IoT and embedded products walks the whole timeline, where penalties reach 15 million euros or 2.5% of worldwide turnover.

The Cyber Resilience Act reporting clock applied to an exploited kernel vulnerability A timeline showing that CVE-2026-53362 was published on 4 July 2026, added to the CISA exploited catalogue on 27 August 2026, and that from 11 September 2026 the Cyber Resilience Act requires an early warning within 24 hours and a full vulnerability notification within 72 hours through the Single Reporting Platform to the national CSIRT and ENISA. From CVE to notification: the clock you inherit Article 14 applies to products already placed on the market 4 July 2026 CVE published by the Linux CNA 27 August 2026 Added to the CISA exploited catalogue 11 September 2026 CRA Article 14 reporting becomes binding 24 hours early warning on an actively exploited flaw 72 hours full notification with corrective measures Single Reporting Platform national CSIRT and ENISA Article 69(3) removes the grandfathering exemption for Article 14 alone: a product sold in 2024 still has to be reported on.
The reporting duty attaches to the fleet you have already shipped, not to the version in your git repository.

How to find out which kernel is actually in your product

Kernel provenance is the chain that links a running binary back to the source tree and vendor tag that produced it. Answering the CRA question starts there, because a manufacturer who cannot name the version in the field cannot say whether a reportable vulnerability is present.

Most teams can answer for the current build and not for the fleet, and those two answers diverge quickly once a product has shipped through several revisions. Our test procedure on an existing product runs in four steps. We read /proc/version and the bootloader banner on a live unit rather than trusting the build manifest. We locate the kernel recipe in the Yocto layer or Buildroot configuration and identify the vendor tag it pins. We diff that tag against the upstream stable branch to measure how far behind it sits. Finally we test whether the stable commits carrying this fix apply cleanly.

Where the schedule risk actually sits

That last step is where the schedule risk lives. A clean cherry-pick is an afternoon of work. A conflicting one against a heavily patched vendor tree is a requalification cycle, which is why we treat it with the same discipline as any other electronic project risk that has to be anticipated rather than discovered.

Keeping the answer available over a product lifetime is a build-system property, not a documentation exercise. A reproducible pipeline of the kind described in our note on embedded DevOps, CI/CD and automated tests turns a fleet-wide kernel query into minutes of work instead of weeks, and the versioning discipline covered in Git for electronics engineers is what lets you prove which source produced which binary when a regulator asks.

What this changes for your SBOM and disclosure policy

A software bill of materials is the machine-readable inventory that makes a question like this answerable in hours rather than weeks. Under the CRA it stops being good practice and becomes the artefact that determines whether you can meet a 24 hour deadline at all.

The kernel is the hardest component to track properly, because it is rarely a versioned dependency in the way a userspace library is. It arrives as a vendor tag, gets patched locally, and then appears in the SBOM as a single line with a version string that may not correspond to anything upstream. An SBOM that records "linux 6.6" without the vendor tag and patch set cannot answer whether 6.6.144 is present, which is the only question that matters here.

Disclosure standards that already apply

The receiving side needs the same preparation. Coordinated Vulnerability Disclosure (CVD) practice is standardised in ISO/IEC 29147 for disclosure and ISO/IEC 30111 for internal handling, and a machine-readable contact point is defined by RFC 9116. Industrial products carry a parallel obligation under IEC 62443, and radio products already face cybersecurity requirements through EN 18031 under the Radio Equipment Directive. None of these replaces the CRA, but a manufacturer who has implemented them is already most of the way to Article 14 readiness.

Despite the paperwork framing, the decisive artefact is operational: a rehearsed path from "we learned about a CVE" to "we filed a notification". Teams that have never run that path discover its gaps under a 24 hour clock, which is the worst possible moment.

Decision matrix: patch, backport, mitigate or accept

A remediation decision is a choice between four responses, and under the CRA only two of them actually remove the vulnerability. The regulation does not mandate a particular remedy, but it does require that the choice be deliberate, documented and reported rather than left implicit.

Moving the whole BSP to a fixed point release is the cleanest answer when the vendor has published one. Backporting the specific commits suits a frozen tree that cannot absorb a branch bump before a certification milestone. Compensating controls, such as removing IPv6 where the product genuinely does not need it, buy time without removing the defect. Accepting the risk is legitimate only when it is written down, justified and reported.

Why disabling IPv6 is rarely available

Despite the temptation to treat the third option as a fix, disabling IPv6 is rarely available on a modern connected product. Thread and Matter are IPv6-native, and several NB-IoT and LTE-M operators run IPv6-only cores, as covered in our comparison of NB-IoT, LTE-M and satellite connectivity and in the broader LPWAN network comparison. Even where the stack can be disabled, doing so on a deployed fleet is itself a field update with its own qualification cost.

Four responses to an exploited kernel vulnerability in a shipped product Four options compared. Update the board support package to a fixed release, which removes the flaw and is preferred when the vendor has published one. Backport the specific commits, which suits a frozen tree before a certification milestone. Apply compensating controls, which buys time without removing the defect. Accept the risk, which is only defensible when documented, justified and reported under the Cyber Resilience Act. Four responses, and what each one costs you Only the first two remove the vulnerability Update the BSP Move to the fixed point release Removes the flaw Needs a vendor release to exist Requalification of the whole image Preferred when available Backport the fix Cherry-pick into the frozen tree Removes the flaw Smallest change to a qualified image May conflict on a patched vendor tree Preferred before a certification date Compensating controls Remove IPv6 if genuinely unused Does not remove the defect Blocked by Thread, Matter, NB-IoT Buys time only Accept the risk Leave the kernel as it is Flaw stays live Only defensible if written down and justified Still reportable under Article 14 Silence is not an option in any column: the reporting duty is independent of which remedy you pick.
The CRA does not require you to choose a particular remedy. It requires you to know which one you chose, and to have said so.

Field report: the update that was not about a CVE

A routine kernel update is the cheapest form of vulnerability response, because it removes flaws you have not yet heard about. On a recent project at AESTECHNO in Montpellier, we moved a customer from 6.6 to the current 6.18 LTS inside their vendor BSP, and the migration took a few days.

Nothing about that work was CVE-driven. The goal was maintenance: stopping the tree from drifting further behind upstream while the product was still straightforward to requalify. We scheduled it as a standing line item rather than as a response to anything, which is why it attracted no urgency and no argument about severity.

We learned afterwards that the 6.6 kernel we had just replaced carried a High-severity CVE. Nobody had raised it at the time of the migration, and the customer never had to make a decision about it, because the fix had already shipped as part of ordinary maintenance.

Why currency beats severity scoring

Contrary to the common assumption that kernel updates should be scheduled by severity score, the update that protected this product was the one nobody could have justified on a CVSS number. No score was in front of us. Severity-driven patching only ever covers flaws that have already been published, which is a strict subset of the flaws actually present in the tree.

One caution from that same project: moving to a newer LTS branch is not by itself a fix for any particular CVE. CVE-2026-53362 affects 6.18 below 6.18.38 exactly as it affects 6.6 below 6.6.144. Branch currency buys a maintained tree and a shorter backport queue, but the point release is what removes a given defect.

Despite the requalification cost, we recommend treating kernel currency as a standing maintenance line rather than an incident response. A few days of planned work, at a moment you choose with test capacity booked, is a different proposition from the same migration run under an Article 14 clock.

Bottom line

CVE-2026-53362 is a defect in the exact long-term kernels that embedded products ship, exploited in the wild, carrying a published mitigation written for a deployment model your device does not use. Five points decide your exposure.

  • Check the version, not the advisory. Fixed at 6.1.177, 6.6.144, 6.12.95, 6.18.38 and 7.1.3. Below those numbers the product is vulnerable, with no partial state in between.
  • Disabling user namespaces protects nothing here. With no containers on the device, the UDPv6 path stays open to any local service account you have already granted to a daemon.
  • Your kernel came from a BSP, not a distribution. Nobody is going to push this fix to you, so the backport and its requalification are yours to schedule.
  • 11 September 2026 turns this into a 24 hour duty. An actively exploited vulnerability in a product with digital elements is exactly the Article 14 trigger case.
  • Grandfathering does not cover reporting. Article 69(3) exempts older products from the technical requirements, never from Article 14.

Kernel provenance under the CRA? AESTECHNO expertise

We audit what is actually running on your fleet and turn it into a defensible position before the reporting duty starts.

  • Fleet-wide kernel and BSP inventory, traced back to the source tree that built it
  • Backport feasibility assessment against your frozen vendor tag
  • Article 14 readiness: CVD policy, intake channel and a rehearsed 24 hour triage path

Free 30 minute audit

Why choose AESTECHNO?

  • 10+ years of experience in embedded systems and connected product design
  • 100% success rate on CE/FCC certifications
  • 65 projects delivered since 2022
  • French electronics design office based in Montpellier

Frequently asked questions

Which kernel versions fix CVE-2026-53362?

The fix landed in 6.1.177, 6.6.144, 6.12.95, 6.18.38 and 7.1.3. Anything from 6.0 up to but not including the fixed release on its branch is affected. The boundary is exact: 6.1.176 is vulnerable and 6.1.177 is not. Check the running kernel with uname -r on a live unit rather than reading the build manifest, because a fleet that has shipped through several revisions usually carries more than one version.

Does disabling user namespaces protect an embedded device?

No. Setting user.max_user_namespaces=0 blocks the container-escape chain that Red Hat documents, which is why the advisory recommends it for enterprise fleets. An embedded product that never creates containers gains nothing from it, because the vulnerable code in __ip6_append_data() is reached through an ordinary UDPv6 socket. Any compromised service account on the device can still trigger the overflow, so the only real remedies are updating the kernel or backporting the fix.

Is my product in scope of CRA Article 14?

If it is a product with digital elements made available on the EU market, then yes, including units sold before the regulation applies in full. Article 69(3) exempts products placed on the market before 11 December 2027 from the technical requirements unless substantially modified, but it explicitly does not exempt them from Article 14. A device sold in 2024 and still supported carries the same reporting duty as one shipped next year.

How fast must we report an exploited vulnerability?

An early warning is due within 24 hours of becoming aware that a vulnerability in your product is being actively exploited, followed by a fuller notification within 72 hours describing corrective or mitigating measures. Severe incidents follow the same two-stage pattern. Notifications go through the Single Reporting Platform, which routes to your national CSIRT and to ENISA, so one filing replaces parallel submissions in each member state.

Can we disable IPv6 instead of patching?

Occasionally, but far less often than manufacturers expect. Thread and Matter are IPv6-native, so a smart-building or consumer device cannot drop it. Several NB-IoT and LTE-M operators run IPv6-only cores. Where IPv6 is genuinely unused, removing it is a legitimate compensating control that reduces exposure, but it does not remove the defect from the image and it does not remove the vulnerability from your reporting obligations.

Who backports the fix into a vendor BSP?

In practice, whoever owns the product. Silicon vendors publish BSP releases on their own cadence, and a tag frozen for a certification campaign will not receive stable-branch updates automatically. That leaves the manufacturer, or its design partner, to cherry-pick the commits, resolve conflicts against local patches and requalify the image. Budgeting that work in advance is far cheaper than discovering the conflict during a 24 hour reporting window.

Does an SBOM alone satisfy Article 14?

No. A software bill of materials tells you what is in the product, which is a prerequisite, but Article 14 concerns notification rather than inventory. You also need a monitoring path that connects a published CVE to your own components, a disclosure policy along the lines of ISO/IEC 29147, and an intake and escalation route capable of producing a filing inside 24 hours. The SBOM makes that possible; it does not make it automatic.

Written by Hugues Orgitello, founder of AESTECHNO, an electronics design office in Montpellier specialising in industrial embedded software, IoT electronics design and CE and RED certification for connected products. Full technical detail on this CVE is published by NVD and its exploitation status by CISA.