CVE-2026-53400

What it actually does

This is a Linux kernel race condition in the I2C core adapter registration path. An I2C adapter can be inserted into the kernel IDR lookup table before the embedded device structure is fully initialized, allowing another code path such as i2c_get_adapter() or an i2c-dev bus notifier to obtain and use a partially initialized adapter. Depending on timing and kernel configuration, this can cause NULL-pointer dereferences, use-after-free conditions, kernel memory corruption, denial of service, or potentially local privilege escalation with kernel-level impact.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local attacks that crash the host or, in a worst case, allow a low-privileged local user to gain elevated privileges. The current exploitation signal is low: EPSS is 0.00103, the issue is not in CISA KEV, is not known to be used in ransomware, and no public exploit maturity is indicated. However, because the flaw is in the kernel, successful exploitation can affect confidentiality, integrity, and availability of the entire system.

How an attack unfolds

An attacker first needs local access to a system running a vulnerable Linux kernel. They then attempt to trigger I2C adapter registration while simultaneously causing another kernel path to look up or interact with that adapter before initialization is complete. This may involve racing adapter creation, hotplug-like behavior, driver paths, or i2c-dev interactions where available. If the race is won, the kernel may dereference uninitialized or freed adapter-related data. The most likely observable outcome is a kernel oops, panic, or service disruption, but under favorable conditions the same primitive could potentially be shaped into memory corruption and privilege escalation.

How to fix it

Apply the vendor-supplied Linux kernel update that includes the I2C core fix for the adapter registration race. If exact fixed versions are not listed by the upstream advisory, use the fixed kernel packages from the relevant Linux distribution or vendor security channel and confirm the changelog includes the patch described as "i2c: core: fix adapter registration race." Where immediate patching is not possible, reduce local attack surface by restricting untrusted shell access, limiting access to /dev/i2c-* devices, disabling unnecessary I2C-related modules or drivers, preventing unprivileged module loading, and ensuring kernel hardening features such as KASLR, SMEP/SMAP, lockdown, and module signature enforcement are enabled where supported.

How to confirm the fix worked

Confirm the running kernel has been upgraded to a vendor build containing the I2C adapter registration race fix. Validate with the distribution package changelog, kernel source changelog, or vendor advisory rather than relying only on version strings, because fixes may be backported. Check whether I2C support is present by reviewing loaded modules, kernel configuration, and /dev/i2c-* exposure. After remediation, reboot into the fixed kernel and verify with uname/package-manager output that the active kernel is the patched one, not only installed on disk. Monitor kernel logs after upgrade for absence of recurring I2C-related oops, KASAN, NULL-pointer, or use-after-free messages during device registration or driver activity.

Typical attack path

1. Obtain local, low-privileged access to a Linux system running an affected kernel.
2. Identify whether I2C support, i2c-dev, relevant drivers, or adapter registration paths are present and reachable.
3. Repeatedly trigger I2C adapter registration or related driver/device activity while racing calls that look up the adapter by ID.
4. Cause i2c_get_adapter() or a notifier-driven path to access an adapter before its embedded device structure is fully initialized.
5. Leverage the resulting NULL-pointer dereference, use-after-free, or memory corruption to crash the kernel or attempt local privilege escalation.

How to detect it

There are no known public exploitation-specific indicators for this vulnerability, and successful exploitation may look like a generic kernel crash or memory-corruption event. To investigate possible prior exploitation, review kernel logs, persistent journal entries, crash dumps, kdump/vmcore data, audit logs, and endpoint telemetry for I2C-related oops or panic events, especially messages involving i2c_get_adapter, i2c-dev, adapter registration, NULL-pointer dereferences, use-after-free, KASAN, or refcount/device lifetime errors. Correlate any such events with local user activity, recent execution of stress tools, driver probing, module load/unload activity, hotplug/device enumeration, access to /dev/i2c-* nodes, and unexplained privilege changes. Treat the listed strings as investigative leads rather than proof of exploitation because similar messages can occur from benign kernel bugs or hardware/driver instability.

• i2c_get_adapter
• i2c-dev
• i2c: core
• i2c_register_adapter
• i2c_add_adapter
• /dev/i2c-
• BUG: KASAN: use-after-free
• use-after-free in i2c_get_adapter
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• kernel BUG at drivers/i2c/
• Oops:
• Kernel panic - not syncing
• general protection fault
• refcount_t: addition on 0; use-after-free

What your security team should do

• Prioritize patching Linux systems that allow local user access, run multi-user workloads, expose /dev/i2c-* devices, or use hardware platforms with active I2C device registration.
• Track vendor kernel advisories and deploy the fixed kernel package that includes the "i2c: core: fix adapter registration race" change.
• Reboot systems after patching and verify the active running kernel is the remediated build.
• Temporarily restrict access to /dev/i2c-* devices and remove unnecessary users from groups that can interact with I2C device nodes.
• Disable or unload unnecessary I2C-related drivers/modules where operationally safe.
• Review recent kernel crash, oops, KASAN, and panic logs for suspicious I2C-related failures that could indicate attempted exploitation or stability impact.
• Because this is not currently KEV-listed and has very low EPSS, handle as important kernel hygiene unless local multi-user exposure or sensitive workloads increase the risk.