Linux i2c Cros EC Tunnel CVE-2025-37781: Probe Deferral Fix

A recently disclosed Linux-kernel vulnerability in the i2c cros‑ec tunnel driver (tracked as CVE‑2025‑37781) can trigger a kernel NULL‑pointer dereference and crash systems that have the affected driver present — the fix upstream defers the driver probe when the Embedded Controller (EC) parent device is not yet available.

Background / Overview​

The i2c‑cros‑ec‑tunnel driver implements an I²C tunnel through a Chrome OS Embedded Controller (EC), exposing devices behind the EC to the main application processor. This driver is used on Chrome OS boards and other hardware designs that expose EC‑connected peripherals to the main CPU via a tunneled I²C bus. The bug arises when the tunnel driver attempts to probe before its EC parent device is attached; in certain build or runtime states the parent device is not found and the probe code dereferences a NULL pointer, producing a kernel oops.
The vulnerability was published and assigned CVE‑2025‑37781 on May 1, 2025. Distributors and trackers (NVD, Amazon/ALAS, Debian/OSV) list the issue as a medium‑severity availability defect and document that the upstream remedy changes the probe path to return -EPROBE_DEFER when the parent EC is absent, allowing a later successful bind once the EC controller is present.

---

What exactly goes wrong: technical root cause​

The bug is a classic kernel probe‑ordering defect coupled with an unsafe dereference. When drivers are built into the kernel (not modules) or when the I²C controller is temporarily unbound, the driver that expects its parent EC device cannot find it during its probe routine. Instead of deferring the probe until the parent appears, the code proceeds and dereferences a pointer that hasn’t been initialized, leading to a NULL pointer dereference at a small offset (0x58 in reported traces). Kernel log excerpts in official trackers show the oops originating from ec_i2c_probe in the i2c_cros_ec_tunnel driver.
Upstream maintainers corrected the logic by returning -EPROBE_DEFER from the probe when the parent EC device is missing. That pattern — deferring probe completion until required resources are present — is the standard kernel approach to avoid transient ordering races between devices and their controllers. The patch was discussed and merged into the i2c host fixes branch; the mailing‑list and patch metadata explicitly reference fixing the original commit that introduced the tunnel driver.

---

Scope and affected systems​

• The driver is specific to Chrome OS EC tunneling scenarios (I²C devices reached via the Chrome OS embedded controller). Systems that do not use this driver are not affected.
• The vulnerability can be triggered both when the driver is built into the kernel image and when module load/unbind sequences are exercised (for example, unbinding the controller and then inserting or binding the tunnel driver). That means both embedded systems and developer/test environments that dynamically unbind and bind device drivers can reproduce the condition.
• Public vulnerability trackers and distro advisories report the problem as a local‑access availability issue (kernel crash/DoS) rather than an information disclosure or privilege elevation flaw; exploitability is limited by the need for local access or the ability to manipulate device driver binding. Many distributors give the CVSS v3.1 vector that indicates a Local attack vector with low privileges required, and the primary impact being Availability: High, while Confidentiality and Integrity are not affected. Administrators should treat the defect as a denial‑of‑service risk for affected hardware.

---

Why this matters: practical impact and risk profile​

A kernel oops triggered by a NULL pointer dereference is a hard failure for a kernel: it can crash the machine or at minimum produce an unrecoverable kernel warning requiring a reboot. For devices that rely on high uptime — embedded endpoints in industrial or kiosk deployments, developer machines used for automated testing, or Chrome OS devices providing managed endpoints — repeated or accidental triggering of this probe path can cause persistent availability issues.
Two real‑world scenarios illustrate the risk:

• A system administrator or developer performing driver experimentation or hot‑unbinding the controller could unintentionally render a device unusable until reboot, causing service disruption.
• A local unprivileged process with the ability to request device bind/unbind (or a misconfiguration that leaves the controller unbound) could intentionally trigger the kernel oops to deny service to the host, creating a straightforward local denial‑of‑service vector.

Although the problem requires specific hardware or configuration, the impact is complete loss of availability on the affected machine while the kernel enters a fault path — a condition that warrants prompt remediation on devices that run the i2c‑cros‑ec‑tunnel driver.

---

What the upstream patch did​

The upstream fix follows the established kernel pattern: the probe handler now checks for the presence of the EC parent device and — if absent — returns -EPROBE_DEFER instead of continuing and dereferencing NULL. Returning -EPROBE_DEFER tells the driver core to try the probe again later, after the controller driver becomes available. The change is minimal but corrects the ordering assumption that caused the vulnerable dereference. The patch discussion and merge notes show the fix being applied to the i2c host fixes branch and queued for stable trees.

---

Where to find patched kernels and distributor guidance​

Multiple distribution trackers and vendor repositories incorporated the fix into security updates and backports. Look for the presence of the patch in your distro’s kernel package changelog or security tracker:

• NVD and mainstream CVE trackers list the vulnerability and its description, useful for baseline identification.
• Amazon/ALAS and Oracle Linux CVE repositories list the CVSS information and platform status; Amazon’s advisory supplies a CVSS v3 score (5.5) and indicates local exploitability with high availability impact.
• OSV/Vulners and distribution advisories show follow‑on DLA entries and backports (Debian DLA references and Ubuntu/other distro updates) indicating specific security updates that include the fix. Administrators should consult their distribution’s security tracker (Debian LTS/DLA, Ubuntu USN, Red Hat Errata) for the exact package and update instructions for their release.

Because the patch was merged into the kernel tree, it is expected to appear in subsequent stable kernels and in distributor backports; the exact package names and version numbers will vary by vendor and kernel branch. Always confirm via your distribution advisory or package manager before deploying.

---

Immediate mitigation options (practical guidance)​

If you manage systems that may include the i2c‑cros‑ec‑tunnel driver and you cannot immediately install a patched kernel, follow these mitigation steps to reduce exposure or avoid accidental crashes:

• Detection first — check whether the driver is present:
• For modular builds: run lsmod | grep cros_ec or modinfo i2c_cros_ec_tunnel to see module presence and metadata.
• Check dmesg or journalctl for lines containing “i2c_cros_ec_tunnel” or the probe oops signature (ec_i2c_probe and NULL pointer deref traces). A failing probe will usually leave a distinctive call trace.
• If the driver is a module, blacklist or remove it until you can patch:
• On many distros, creating a /etc/modprobe.d/blacklist‑i2c_cros_ec.conf with a blacklist i2c_cros_ec_tunnel line and then rebooting prevents module insertion.
• If already loaded, remove the module with rmmod i2c_cros_ec_tunnel (if no other modules depend on it). Note: blacklisting is ineffective for drivers compiled into the kernel image.
• For kernels with the driver built‑in, the practical options are:
• Install a patched kernel from your distribution (preferred) — verify the vendor changelog includes CVE‑2025‑37781 or the i2c probe fix.
• Rebuild a kernel with the driver disabled (CONFIG_I2C_CROS_EC_TUNNEL=n) if you have the ability to rebuild and deploy custom kernels in your environment.
• If feasible, avoid unbinding the controller device in production workflows that might trigger the race.
• As a short‑term workaround for testing/dev boxes, avoid operations that unbind or rebind the I²C controller driver while the tunnel driver is present.

These mitigations will reduce accidental exposure; the only reliable permanent fix remains installing a kernel that includes the upstream probe‑defer change.

---

How to check whether you’re affected (step‑by‑step checklist)​

• Identify whether the i2c tunnel driver is present:
• Run: uname -r ; modinfo i2c_cros_ec_tunnel || true
• If modinfo returns data, you have the module available; check lsmod | grep i2c_cros_ec_tunnel.
• If the driver is built in, check your kernel config:
• zcat /proc/config.gz | grep CONFIG_I2C_CROS_EC_TUNNEL
• If the option is set to y, the driver is built into the kernel image (not removable without a kernel replacement).
• Inspect logs for evidence of the OOPS:
• dmesg | grep -i 'ec_i2c_probe|i2c_cros_ec_tunnel|NULL pointer dereference' should reveal the probe failure signature if it has happened. Public CVE traces show the dereference at address 0x58 in reported oopses.
• Verify distributor patch availability:
• Consult your distro’s security tracker (Debian/Ubuntu/Red Hat/SUSE/Amazon Linux) for CVE‑2025‑37781 entries or for kernel package changelogs that reference the i2c probe fix. Use the vendor advisory to choose the correct kernel package to apply.

Follow this checklist before attempting to update production systems; ensure vendor kernels are tested in your environment before mass deployment.

---

Detection and monitoring guidance for operators​

• Add a simple dmesg/journal rule to alert on OOPS signatures:
• Look for “BUG: kernel NULL pointer dereference” paired with “i2c_cros_ec_tunnel” or “ec_i2c_probe”.
• For managed fleets, create a query against system logs (ELK/ Splunk / OSQuery) to find nodes that have ever logged i2c_cros_ec_tunnel events or related traces. These systems will be the primary candidates for remediation.
• In environments where device binding operations are automated (CI systems, hardware labs), add preflight checks to avoid driver rebinds that might hit the probe path until kernels are patched.

All of these detection actions will help prioritize which hosts should be patched first.

---

Responsible disclosure and timeline (concise)​

• The public record shows the fix and CVE assignment were published on May 1, 2025. The upstream kernel patch was merged into the i2c host fixes series and propagated as stable backports in vendor trees and distribution advisories. Administrators should assume the fix is available through vendor packages and plan updates accordingly.
• There are no widely reported exploits in the wild that chain this defect into remote compromise; the risk is primarily local denial of service. Nevertheless, the presence of a kernel oops on any production endpoint is operationally unacceptable, and patching should be treated as standard security maintenance.

---

Recommendations for sysadmins and OEMs​

• Prioritize patching of systems where the driver is present. If you manage Chrome OS fleets or custom embedded Linux devices that include an EC tunnel, schedule updates quickly — these devices are the most likely to be affected.
• Validate the vendor kernel changelog or security advisory contains the i2c probe deferral fix before rolling to production. If you rely on vendor kernels (Chrome OS OEMs, embedded vendors), ask for explicit confirmation that their build includes the upstream fix.
• For product teams and OEMs: ensure device driver probe ordering is robust during integration testing and include automated tests that simulate controller unbind/rebind to catch probe‑ordering regressions early.
• For DevOps: update monitoring and alerting to pick up kernel oops traces so you can quickly detect any post‑patch regressions or latent issues introduced during kernel updates.

---

Why small probe fixes matter (broader perspective)​

Probe‑ordering and dependency handling are recurring classes of kernel bugs that seem small in code delta but have outsized operational impact. A missed check or an assumption that the parent device exists can convert normal runtime device management operations into system‑wide outages. The i2c‑cros‑ec‑tunnel fix is a reminder that defensive checks (like returning -EPROBE_DEFER) are essential in kernel subsystems where device attachment order is non‑deterministic, especially on complex embedded platforms. Upstream kernel reviewers and integrators should prioritize such defensive patterns when reviewing new drivers.

---

Final verdict and action plan (concise)​

• Severity: Medium (denial‑of‑service via kernel oops), with a CVSS baseline around 5.5 per vendor trackers. The impact is availability, and exploitability is local or requires the ability to manipulate device binding.
• Immediate action for operators:
• Detect: identify hosts with the i2c_cros_ec_tunnel driver and search logs for probe oops.
• Mitigate: blacklist or remove the module where possible; avoid unbinding operations that reproduce the failure.
• Patch: apply vendor/distribution kernel updates that include the upstream probe‑defer fix as soon as they are available. Confirm via distro/security tracker entries.

Patching is the definitive remediation; short‑term mitigations are useful when patch windows are constrained, but they are no substitute for installing a kernel that contains the upstream fix.

---

CVE‑2025‑37781 is a narrowly scoped but operationally meaningful kernel defect: the code change is small, the concept is straightforward — defer probing when a required parent is missing — but the consequences are real for affected devices. Systems teams and OEMs should treat the advisory as a routine but important maintenance task: detect, contain, and update promptly to remove a trivial path to system unavailability.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center