A small race in the Linux EEPROM stack has produced an outsized question for Microsoft customers: when the upstream Linux kernel patched CVE‑2024‑35848 — "eeprom: at24: fix memory corruption race condition" — Microsoft’s initial public attestation narrowed immediate scope to the Azure Linux distribution. That statement answers part of the story, but it does not complete it: the true extent of exposure inside Microsoft’s product portfolio depends on which Microsoft products actually ship or operate a Linux kernel build that includes the at24 driver (or expose an at24-based nvmem device to other kernel components). This feature article explains what CVE‑2024‑35848 is, why it matters, how to determine whether a given Microsoft product is affected, and what practical steps administrators and engineers should take now.
The flaw sits in the Linux kernel’s at24 EEPROM driver, a long-standing generic driver for many I²C EEPROM chips. At a high level the bug is a race condition that can lead to memory corruption when the kernel registers an nvmem (non‑volatile memory) device for an EEPROM that later proves inaccessible. Under the problematic sequence, the nvmem device is registered, a read fails, the device is torn down, and — crucially — another driver can still access the nvmem device while it references freed or invalid memory. The upstream fix simply moves the failure point so the nvmem device is not registered until the driver has validated access; this prevents the exposed window that could trigger use‑after‑free or memory corruption.
Technically the issue is a kernel‑level race (CWE‑362 / concurrent execution using shared resource with improper synchronization) rather than a userland library bug. That distinction matters: the attack surface consists of any product or image that ships a Linux kernel binary with the impacted code path enabled or that runs workloads atop a vulnerable host kernel.
Microsoft’s public message about this CVE has focused on the Azure Linux distribution. Microsoft has stated that Azure Linux is kept current with up‑to‑date open source libraries and that, at the time of the message, Azure Linux is the Microsoft product known to include the vulnerable component. Microsoft also committed to update the CVE attestation if further impact to additional Microsoft products is found.
Longer, actionable answer:
However, there are practical limitations to the statement:
Operators must therefore take a pragmatic, evidence‑based approach: inventory kernels, check for at24 presence, apply vendor patches when available, and use module‑level mitigations where patching is delayed. Microsoft’s commitment to transparency and product attestations helps reduce uncertainty, but it does not eliminate the need for customer verification and action.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The flaw sits in the Linux kernel’s at24 EEPROM driver, a long-standing generic driver for many I²C EEPROM chips. At a high level the bug is a race condition that can lead to memory corruption when the kernel registers an nvmem (non‑volatile memory) device for an EEPROM that later proves inaccessible. Under the problematic sequence, the nvmem device is registered, a read fails, the device is torn down, and — crucially — another driver can still access the nvmem device while it references freed or invalid memory. The upstream fix simply moves the failure point so the nvmem device is not registered until the driver has validated access; this prevents the exposed window that could trigger use‑after‑free or memory corruption.Technically the issue is a kernel‑level race (CWE‑362 / concurrent execution using shared resource with improper synchronization) rather than a userland library bug. That distinction matters: the attack surface consists of any product or image that ships a Linux kernel binary with the impacted code path enabled or that runs workloads atop a vulnerable host kernel.
Microsoft’s public message about this CVE has focused on the Azure Linux distribution. Microsoft has stated that Azure Linux is kept current with up‑to‑date open source libraries and that, at the time of the message, Azure Linux is the Microsoft product known to include the vulnerable component. Microsoft also committed to update the CVE attestation if further impact to additional Microsoft products is found.
What exactly was fixed (technical details)
The vulnerable sequence
- The at24 driver probes an EEPROM over I²C and — as part of its workflow — registers an nvmem device into the kernel nvmem subsystem.
- If the EEPROM is not accessible (for example, due to transient I²C failures or a device that disappears during probe), the driver attempted the registration before validating the read path in a safe place.
- If registration occurred and subsequent operations failed, the driver tore down the device. But another kernel component could reference the registered nvmem device after teardown.
- This leads to out‑of‑bounds or use‑after‑free style memory corruption inside kernel space, with the most likely impact being system instability or denial of service (kernel panic).
The fix
- Upstream developers adjusted the probe path so that the check that would trigger failure is moved before nvmem device registration. In short: don't register a device until you can guarantee it is usable.
- The patch is straightforward and small in code‑change surface, but important because it closes a window in which concurrent access could dereference invalid memory.
Which kernel versions are fixed and which were affected
Upstream and downstream distributors produced patches and released fixes in tagged kernel versions shortly after the upstream fix was accepted. Multiple stable kernels received backports; distributions patched their packages as part of regular maintenance. In practical terms:- Patches were backported to common LTS and stable trees used by major distributions.
- Many Linux distribution kernel packages that include at24 support were updated shortly after the upstream fix.
Is Azure Linux the only Microsoft product that includes the vulnerable library?
Short answer: No — Azure Linux is not the only Microsoft product that could include the vulnerable code, but it may be the only Microsoft product that Microsoft has formally attested as including it at the time of their notice.Longer, actionable answer:
- The CVE is a Linux kernel bug. Any Microsoft product or service that ships, distributes, runs, or manages a Linux kernel binary that includes the at24 code path can be in scope.
- Microsoft explicitly identified Azure Linux as a product that includes the open‑source code in question and therefore as potentially affected. That is an important, transparent attestation, and Microsoft has said it will update the CVE attestation if impact to other Microsoft products is found.
- However, multiple other Microsoft products and services either ship a Linux kernel or enable Linux kernels to run under Microsoft control. Those include (but are not limited to):
- Windows Subsystem for Linux (WSL, WSL2) — WSL2 runs a Microsoft‑built Linux kernel image inside a lightweight VM. Because Microsoft ships and updates that kernel, any kernel‑level vulnerability present in the WSL kernel configuration or module set can affect WSL instances.
- Azure Virtual Machine images and marketplace images — Azure publishes and operates VM images from Linux vendors, but Microsoft also offers Azure‑tuned kernels and images that may contain vendor or Microsoft patches. If an Azure VM image ships a vulnerable kernel, a VM running that image is affected.
- Managed services that run or control kernel versions — examples include node images for managed Kubernetes (AKS) or Azure App Service stacks that rely on underlying VM kernel versions. If the managed node image or host kernel includes the vulnerable code, workloads will be affected.
- Third‑party images or appliances distributed by Microsoft — Microsoft distributes many vendor images and appliances in its marketplaces; the kernel they run determines exposure.
- Conversely, many Microsoft products do not ship or operate Linux kernels (for example, native Windows Server components or pure Windows userland services) and are therefore not directly affected by a Linux kernel CVE. But Microsoft’s cloud environment runs a mixture of tenant‑owned kernels (the VM guest), publisher‑supplied images, and Microsoft‑maintained host/guest kernels — each must be assessed separately.
Why Microsoft’s attestation matters — and its limits
Microsoft’s public statement that Azure Linux includes the component is helpful for customers running that distro: it creates a clear remediation path and a direct line of responsibility. Microsoft’s commitment to publish CSAF/VEX attestations adds transparency when it is available.However, there are practical limitations to the statement:
- Attesting that one product includes the code is a narrow, targeted confirmation; it is not an exhaustive inventory of all the places Microsoft uses or distributes Linux kernel binaries.
- Microsoft’s product family contains items that intentionally include Linux kernels (WSL2), host/guest kernels in Azure, and Azure‑tuned images. Each product’s kernel packaging and configuration varies, so a centralized attestation takes time and manual review.
- Microsoft’s attestation process is ongoing; they’ve indicated they will update the CVE entry if they identify further impact. Customers should not interpret the absence of additional product names in Microsoft’s attestation as proof of safety.
How to determine whether a Microsoft product or service you rely on is affected
Below are practical, prioritized checks you can run yourself or demand from your platform owner or vendor. These checks assume you have administrative access to the environment or can request the data from a provider.1. Identify the kernel binary version and build
- Run: uname -a to determine the kernel version string.
- For WSL2: check the WSL2 kernel version presented to the distro instance (the kernel the WSL VM is running). WSL kernels are updated via Microsoft updates or the Store in some configurations; administrators can also use custom kernels via .wslconfig.
2. Check for the at24 module or driver exposure
- Check built‑in configuration flags: some systems export their kernel config at /proc/config.gz. If present, search for CONFIG_AT24 or related options.
- Check module lists:
- Look under /lib/modules/$(uname -r)/kernel/drivers/i2c/chips/ for an at24.ko file.
- Use modinfo at24 (if present) to find version and build info.
- Check sysfs for nvmem/eeprom nodes:
- Look under /sys/bus/nvmem/devices/ and /sys/bus/i2c/devices/ for eeprom or nvmem entries associated with at24 drivers.
- Presence of these sysfs entries shows the driver is active or present in the kernel.
3. For hosted/cloud images and managed node pools
- For Azure VM images: query the image publisher and kernel package version. Compare the kernel package version to known patched versions.
- For AKS node pools and other managed node images: confirm which kernel image is used and whether Microsoft or the distribution vendor has applied the CVE fix.
- If you rely on marketplace images, ask the vendor for evidence of kernel package updates covering CVE‑2024‑35848.
4. For WSL (Windows Subsystem for Linux)
- Determine whether WSL is using the Microsoft shipped kernel or a custom kernel. If it is using the Microsoft kernel, check the WSL kernel’s build and module set for at24 presence.
- If using a custom kernel via .wslconfig, the same kernel‑inspection steps apply as for VMs.
5. For environments you cannot inspect directly
- If you are a tenant in Azure and cannot access the host kernel (for example, for certain platform services), request the vendor/service owner attest the presence or absence of the vulnerable kernel module.
- Demand a CSAF/VEX or other vendor‑issued machine‑readable disclosure for the specific product image or service.
Remediation and mitigation — practical steps
- Patch promptly
- The authoritative fix is to upgrade to a kernel version that includes the upstream at24 change or apply the vendor patch. Vendors and distributors published updated kernel packages soon after the fix.
- For managed instances (e.g., Azure Linux images), apply the vendor‑supplied updates as directed by Microsoft or the distribution maintainer.
- Query and remove unnecessary modules
- If the at24 driver is built as a module and you do not need EEPROM support on the host, consider unloading the module and blacklisting it to prevent automatic loading as a defense‑in‑depth measure.
- Isolate untrusted users
- The vulnerability's realistic exploitation requires local code execution or the ability to trigger kernel probe behavior for EEPROM devices. Tighten controls on local access, untrusted containers, and untrusted code execution paths on systems that cannot be patched immediately.
- For WSL users
- Ensure Windows Update and the WSL package are applied; Microsoft patches the WSL kernel via updates in many release channels.
- If you use a custom kernel, rebuild it with the upstream patch applied or switch temporarily to the Microsoft‑supplied kernel once the fix is available.
- For cloud images and managed node pools
- Coordinate updates with the image publisher or Microsoft, and follow their remediation guidance for node reimaging, rolling updates in a cluster, or kernel package updates.
- For Kubernetes clusters, perform controlled rolling updates to minimize downtime.
- Monitor for signs of exploitation
- Watch kernel logs (dmesg, journalctl) for unusual panic logs, oops reports, memory corruption, or sporadic module unloads/registers tied to nvmem/eeprom operations.
- Correlate host instability with times of device probe or module registration events.
Risk analysis: impact, exploitability, and priority
- Exploitability: the flaw is a kernel race that requires local interaction with kernel subsystems that manage EEPROM/nvmem device registration. In most server or VM contexts, direct access to I²C EEPROM hardware is uncommon — that reduces remote exploitation utility. The most likely vectors are local attackers, malicious drivers, or misbehaving kernel modules. For scenarios involving embedded systems, IoT endpoints, or appliances where EEPROM devices are common, the risk profile is higher.
- Impact: vendor advisories and scoring indicated moderate severity overall, with the primary concrete impact being availability — the vulnerability can cause system instability or a kernel panic. For systems where uptime is critical, the availability impact raises the priority of patching.
- Priority: if your environment uses kernels that include at24 (embedded devices, edge appliances, some cloud images with broad driver sets, or developer platforms like WSL that include many modules), treat remediation as a medium‑high priority. If your environment is a minimal server kernel with no at24 support or where the at24 module is absent, the practical risk is lower.
Special considerations for containerized workloads and multi‑tenant cloud
This CVE underscores the classic host‑kernel threat model: containers share the kernel, not just userland. If the host kernel is vulnerable, containers running on it inherit the vulnerability even if the container images themselves do not include the vulnerable code. Therefore:- For tenants running containers in Azure or other clouds, verify the host kernel (node or VM) for the CVE patch status.
- For managed container services (e.g., AKS), verify whether Microsoft has applied the kernel fix to underlying node images or if node pools need reimaging.
- For marketplace or BYO images, ensure kernel updates are included in your CI/CD image‑build and deployment pipelines.
Recommended operational checklist (quick reference)
- Inventory: Enumerate all systems, VMs, and platforms where you run Linux kernels — including WSL2 instances — and collect kernel versions and module lists.
- Detect: On each host, search for CONFIG_AT24 in /proc/config.gz (when available), presence of /lib/modules/.../drivers/i2c/chips/at24, or /sys/bus/nvmem/devices/* entries.
- Patch: Apply the vendor‑supplied kernel updates that contain the upstream at24 fix; for Microsoft‑supplied kernels (Azure Linux, WSL), apply updates distributed by Microsoft.
- Mitigate: If patching is delayed, unload/blacklist the at24 module where possible, and harden local access to prevent unprivileged users from provoking kernel probe sequences.
- Validate: After patching, confirm that the kernel version or upstream commit includes the at24 change, and monitor for kernel panics or OOPS messages during device probe operations.
- Communicate: If you are a service provider or platform owner, publish a clear attestation to customers indicating whether your product includes the affected code and what remediation steps you have taken.
Critical commentary: transparency, timing, and customer responsibility
Microsoft’s initial narrow attestation tied to Azure Linux is a realistic first step — it is easier to make an explicit statement about a single product than to exhaustively inventory every internal build, marketplace image, or managed service. Microsoft’s stated process to publish CSAF/VEX documents helps customers interpret vendor risk. That said, customers and operators must still operationalize due diligence:- Vendor attestations are helpful but not a substitute for customer verification in environments where the host kernel is operator‑controlled or where third‑party images are used.
- For Microsoft products such as WSL2, which ship a Microsoft‑built Linux kernel, customers should treat WSL as a kernel distribution that must be verified and patched like any other kernel — do not assume it is unaffected simply because it is a Windows feature.
- Cloud tenants should pay attention to whether they control the guest kernel (they do inside the VM) or whether the provider controls a host kernel that could expose workloads indirectly — the appropriate mitigation differs.
Conclusion
CVE‑2024‑35848 is a kernel‑level race in the at24 EEPROM driver that can cause memory corruption and destabilize systems that include that driver. Microsoft’s public notice identifying Azure Linux as a product that includes the vulnerable open‑source component is a valuable datapoint, but it is not a guarantee that no other Microsoft product includes the affected kernel code. Any Microsoft product that ships or operates a Linux kernel build — including WSL2, Azure VM images, managed node images, and marketplace appliances — could contain the vulnerable code depending on kernel configuration and module sets.Operators must therefore take a pragmatic, evidence‑based approach: inventory kernels, check for at24 presence, apply vendor patches when available, and use module‑level mitigations where patching is delayed. Microsoft’s commitment to transparency and product attestations helps reduce uncertainty, but it does not eliminate the need for customer verification and action.
Source: MSRC Security Update Guide - Microsoft Security Response Center
