CVE-2026-53400 addresses a long-standing race in the Linux I2C core that can expose partially initialized I2C adapter objects to other kernel code, potentially causing NULL-pointer dereferences or use-after-free conditions. The flaw has now been published in the NVD and assigned fixes in Linux stable releases 6.12.95, 6.18.38, and 7.1.3, with the fix also present from Linux 7.2-rc1 onward.
For Windows administrators, the immediate relevance is primarily WSL 2, custom Linux kernels, and Linux-capable infrastructure managed from Windows. This is not a vulnerability in the Windows kernel, nor is it evidence of a flaw in the Windows I2C stack. But a Windows endpoint or development workstation running an affected WSL 2 kernel—or a custom kernel through
The NVD record, sourced from kernel.org and published July 19, describes the issue in
That ordering mistake matters because I2C is a foundational Linux hardware bus subsystem. It is routinely involved in sensors, embedded controllers, display components, power-management hardware, touch devices, and peripheral controllers. On conventional desktop PCs, an exploitable path may be less obvious than it is on embedded hardware, but the bug lives in shared kernel infrastructure rather than an isolated optional driver.
The vulnerable logic centers on a classic concurrency problem: publishing an object before its construction is complete. Linux’s I2C core keeps adapters in an IDR, an integer-keyed registry used to map a bus number to a corresponding adapter structure.
Before the fix, there was a period in which the adapter was discoverable through the IDR even though the device had not been initialized. Code running concurrently could obtain the reference and touch incomplete state. As the CVE description notes, that can result in NULL-pointer dereferences or use-after-free behavior.
The patch corrects the registration sequence so the adapter and its device are initialized before the adapter is made available for lookup. There is one important ordering constraint: the
That may sound like a fine distinction, but it is exactly where kernel race fixes tend to live. The repaired sequence is not simply “move registration later.” It establishes an order that satisfies two competing requirements: fully initialize the adapter before general discovery, while still publishing it early enough for the I2C userspace device interface to find it during notifier processing.
The age of a bug is not a severity rating. NVD had not assigned CVSS 3.x or CVSS 4.0 scores as of July 20, and the record does not identify a public proof of concept, confirmed exploitation, or a specific privilege boundary crossed by the race. Organizations should avoid converting the mention of use-after-free into an unsupported claim of reliable code execution.
Still, kernel use-after-free bugs deserve prompt patch review, even when exploitability remains unproven. A crash can create an availability problem on its own. In a more favorable attack scenario, memory-lifetime defects can become security issues, particularly where an attacker can influence device arrival, driver binding, hot-plug behavior, or hardware-facing interfaces.
The fix was developed as part of a wider I2C adapter-registration cleanup series. The Linux kernel mailing-list discussion describes several closely related corrections, including failures that could hang adapter registration, cause probe-deferral loops, mishandle debugfs directory creation, and race during deregistration. That broader context is useful: CVE-2026-53400 is a discrete tracked vulnerability, but it sits inside an area of code that has recently received concentrated lifecycle and error-handling scrutiny.
That separation has practical implications. A fully patched Windows 11 PC is not necessarily running the newest Microsoft-packaged WSL kernel, and a current WSL application package does not by itself prove that the active kernel includes this particular upstream stable backport. Conversely, a Linux distribution’s
Microsoft’s public WSL2-Linux-Kernel project tracks upstream stable kernels but carries Microsoft-specific integration and configuration work. Its release listing recently identified
Custom kernels require even more direct review. WSL supports a
Then, from each relevant WSL distribution, verify the actual running kernel:
A kernel reporting 6.12.95 or later in the 6.12 branch, 6.18.38 or later in the 6.18 branch, or 7.1.3 or later in the 7.1 branch contains the upstream stable fix according to the CVE record. A kernel on a different vendor branch must be checked against that vendor’s advisory or changelog; version numbers alone are not always conclusive because distributions frequently backport security fixes without changing to the newest upstream point release.
For WSL fleets, endpoint-management teams should also identify machines using a custom
The NVD entry is newly published, and its lack of CVSS scoring means the formal severity picture may still change. What is already clear is the remediation target: remove the window in which an I2C adapter can be found before its device backing is ready. Windows users do not need to patch Windows for CVE-2026-53400, but WSL 2 users and Linux kernel owners should verify the precise kernel they are actually booting before assuming their update cadence has covered it.
For Windows administrators, the immediate relevance is primarily WSL 2, custom Linux kernels, and Linux-capable infrastructure managed from Windows. This is not a vulnerability in the Windows kernel, nor is it evidence of a flaw in the Windows I2C stack. But a Windows endpoint or development workstation running an affected WSL 2 kernel—or a custom kernel through
.wslconfig—may carry the vulnerable Linux code.The NVD record, sourced from kernel.org and published July 19, describes the issue in
drivers/i2c/i2c-core-base.c. Kernel developer Johan Hovold’s patch series identifies the affected path as adapter registration: an I2C adapter could be inserted into the core’s ID registry before its embedded device structure was fully initialized. Another caller could then locate that adapter through i2c_get_adapter() and obtain a reference to an object that was not yet safe to use.That ordering mistake matters because I2C is a foundational Linux hardware bus subsystem. It is routinely involved in sensors, embedded controllers, display components, power-management hardware, touch devices, and peripheral controllers. On conventional desktop PCs, an exploitable path may be less obvious than it is on embedded hardware, but the bug lives in shared kernel infrastructure rather than an isolated optional driver.
The dangerous interval was small, but real
The vulnerable logic centers on a classic concurrency problem: publishing an object before its construction is complete. Linux’s I2C core keeps adapters in an IDR, an integer-keyed registry used to map a bus number to a corresponding adapter structure. i2c_get_adapter() looks up an adapter by ID and takes a reference on its embedded struct device.Before the fix, there was a period in which the adapter was discoverable through the IDR even though the device had not been initialized. Code running concurrently could obtain the reference and touch incomplete state. As the CVE description notes, that can result in NULL-pointer dereferences or use-after-free behavior.
The patch corrects the registration sequence so the adapter and its device are initialized before the adapter is made available for lookup. There is one important ordering constraint: the
i2c-dev character device is registered from a bus notifier and itself calls i2c_get_adapter(). The adapter must therefore reach the registry before that notifier-driven registration begins—but not before its basic device state exists.That may sound like a fine distinction, but it is exactly where kernel race fixes tend to live. The repaired sequence is not simply “move registration later.” It establishes an order that satisfies two competing requirements: fully initialize the adapter before general discovery, while still publishing it early enough for the I2C userspace device interface to find it during notifier processing.
A fix for code introduced in Linux 2.6.22
The upstream patch marks the issue as originating with commit6e13e6418418, “i2c: Add i2c_add_numbered_adapter(),” and identifies Linux 2.6.22 as the first affected release. That puts the underlying logic more than 19 years old, although the practical impact depends heavily on the kernel configuration, the drivers present, timing, and whether a particular system exercises the registration path concurrently.The age of a bug is not a severity rating. NVD had not assigned CVSS 3.x or CVSS 4.0 scores as of July 20, and the record does not identify a public proof of concept, confirmed exploitation, or a specific privilege boundary crossed by the race. Organizations should avoid converting the mention of use-after-free into an unsupported claim of reliable code execution.
Still, kernel use-after-free bugs deserve prompt patch review, even when exploitability remains unproven. A crash can create an availability problem on its own. In a more favorable attack scenario, memory-lifetime defects can become security issues, particularly where an attacker can influence device arrival, driver binding, hot-plug behavior, or hardware-facing interfaces.
The fix was developed as part of a wider I2C adapter-registration cleanup series. The Linux kernel mailing-list discussion describes several closely related corrections, including failures that could hang adapter registration, cause probe-deferral loops, mishandle debugfs directory creation, and race during deregistration. That broader context is useful: CVE-2026-53400 is a discrete tracked vulnerability, but it sits inside an area of code that has recently received concentrated lifecycle and error-handling scrutiny.
Why Windows shops should check WSL rather than Windows Update history
Microsoft packages the WSL 2 Linux kernel separately from the core Windows operating system. Microsoft’s WSL documentation says the kernel is delivered through Microsoft Update, whilewsl --update updates WSL to the latest available version and wsl --status reports the installed kernel version.That separation has practical implications. A fully patched Windows 11 PC is not necessarily running the newest Microsoft-packaged WSL kernel, and a current WSL application package does not by itself prove that the active kernel includes this particular upstream stable backport. Conversely, a Linux distribution’s
apt, dnf, or zypper update inside WSL normally updates userspace packages; it does not replace Microsoft’s default WSL 2 kernel.Microsoft’s public WSL2-Linux-Kernel project tracks upstream stable kernels but carries Microsoft-specific integration and configuration work. Its release listing recently identified
linux-msft-wsl-6.18.26.1 as based on stable Linux 6.18.26. Because CVE-2026-53400 is listed as fixed in Linux 6.18.38, administrators should not infer coverage from the major-and-minor branch alone. The relevant question is the exact kernel build currently running and whether Microsoft has incorporated the backport.Custom kernels require even more direct review. WSL supports a
kernel setting in %UserProfile%\.wslconfig, allowing an organization or developer to boot WSL 2 with an absolute path to a custom Linux kernel image. That is useful for driver development and specialized workloads, but it shifts patch tracking from Microsoft to the team that builds and deploys that image.Version checks should drive the response
The first response should be inventory, not emergency remediation. On a WSL-enabled Windows device, run:
Code:
wsl --status
wsl --version
wsl --updateuname -rA kernel reporting 6.12.95 or later in the 6.12 branch, 6.18.38 or later in the 6.18 branch, or 7.1.3 or later in the 7.1 branch contains the upstream stable fix according to the CVE record. A kernel on a different vendor branch must be checked against that vendor’s advisory or changelog; version numbers alone are not always conclusive because distributions frequently backport security fixes without changing to the newest upstream point release.
For WSL fleets, endpoint-management teams should also identify machines using a custom
.wslconfig, developer-owned kernel images, and distributions running outside WSL. The latter include Linux virtual machines in Hyper-V, Azure workloads, lab appliances, CI runners, and embedded boards provisioned from Windows administrative systems. Each has its own kernel supplier and update channel.The NVD entry is newly published, and its lack of CVSS scoring means the formal severity picture may still change. What is already clear is the remediation target: remove the window in which an I2C adapter can be found before its device backing is ready. Windows users do not need to patch Windows for CVE-2026-53400, but WSL 2 users and Linux kernel owners should verify the precise kernel they are actually booting before assuming their update cadence has covered it.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:03:23-07:00
NVD - CVE-2026-53400
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:03:23-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
