CVE-2026-64237

What it actually does

This flaw is an out-of-bounds read in the Linux kernel elan_i2c input driver. The driver did not verify that an ELAN firmware blob was large enough to contain the expected firmware pages and trailing signature before reading from it. A malformed or truncated firmware file could cause the kernel to read past the end of the allocated firmware buffer. The most likely technical outcomes are kernel memory disclosure to adjacent reads, driver malfunction, or a kernel crash/panic depending on build options, memory layout, and error handling. Exploitation generally requires the attacker to influence the firmware file consumed by the driver or the firmware update/load path, which usually implies local privileged access, compromise of the firmware distribution/update mechanism, or physical/supply-chain control of the device firmware source.

Why it matters to the business

The primary business risk is endpoint or server instability where affected ELAN input hardware and the vulnerable kernel driver are present. Successful exploitation could disrupt user devices through kernel crashes or support-impacting input-device failures, and in less likely scenarios may expose kernel memory. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, kernel memory-safety bugs should still be remediated through standard kernel update cycles because they affect a privileged trust boundary.

How an attack unfolds

An attacker first needs a path to supply or modify the firmware blob that the elan_i2c driver will load, such as write access to the system firmware directory, compromise of a firmware update channel, malicious local administrative activity, or control over a provisioning image. The attacker then provides a deliberately undersized ELAN firmware file that lacks the expected number of pages or the trailing signature. When the affected kernel driver attempts to validate or process the firmware, it reads beyond the end of the firmware buffer. Depending on kernel configuration and runtime conditions, this can trigger diagnostic warnings, a kernel oops/panic, driver failure, or potentially expose adjacent kernel memory. Because replacing firmware files normally requires elevated privileges, this is most plausibly used as part of a local post-compromise action, denial-of-service technique, or supply-chain/provisioning abuse rather than as an initial remote compromise vector.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the upstream fix for elan_i2c firmware size validation. No exact fixed package versions were provided in the input, so use the distribution or appliance vendor advisory to identify the corrected kernel build for each platform. Where immediate patching is not possible, reduce exposure by restricting write access to firmware directories such as /lib/firmware and /usr/lib/firmware, enforcing package and firmware integrity verification, limiting use of untrusted firmware update tools, and disabling or unloading the elan_i2c driver only if the affected ELAN input hardware is not required and the operational impact is acceptable. Reboot into the patched kernel after installation; installing the package alone is insufficient if the system continues running an older vulnerable kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor build containing the fix. Validate with uname -r, package-manager queries, and vendor changelogs for references to this issue or the patch title "Input: elan_i2c - validate firmware size before use". Check whether the elan_i2c module is loaded with lsmod or modinfo, and prioritize systems where ELAN I2C input hardware is present. Review firmware file ownership and integrity under system firmware directories and confirm they are managed by trusted packages or firmware update tooling. After patching and rebooting, monitor dmesg or journalctl -k while initializing affected hardware or performing approved firmware update workflows to ensure there are no kernel oops, KASAN, or elan_i2c firmware parsing errors.

Typical attack path

1. Gain the ability to modify or supply the ELAN firmware blob used by the Linux system, typically through local privileged access, compromised update infrastructure, or a tampered system image.
2. Place a malformed or truncated firmware file where the kernel firmware loader or update workflow will retrieve it.
3. Trigger the elan_i2c driver to load or process the firmware, such as through boot, device initialization, driver reload, or firmware update activity.
4. The vulnerable driver reads past the end of the firmware buffer while looking for expected firmware pages or the signature at the end of the blob.
5. The system may log kernel memory-safety warnings, experience input-device failure, crash, or expose unintended kernel memory depending on system configuration.

How to detect it

Look for evidence that a malformed ELAN firmware blob was introduced or processed. Relevant sources include kernel logs from dmesg, journalctl -k, /var/log/kern.log, and /var/log/messages; firmware update logs from fwupd or vendor tooling; file integrity monitoring for /lib/firmware and /usr/lib/firmware; package-manager logs showing kernel or firmware package changes; and EDR telemetry for privileged writes into firmware directories. Search for elan_i2c driver messages near kernel oops, panic, page fault, or KASAN out-of-bounds reports. Investigate unexpected firmware file size changes, newly created ELAN-related firmware files, firmware files not owned by a trusted package, or writes to firmware paths by unusual processes. Because no public exploitation or threat actor activity is reported, detection should focus on suspicious local firmware tampering and kernel crash artifacts rather than known attacker infrastructure.

• elan_i2c
• Input: elan_i2c - validate firmware size before use
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: KASAN
• Oops:
• kernel panic
• general protection fault
• page fault
• /lib/firmware/
• /usr/lib/firmware/
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• fwupd
• fwupdmgr
• modprobe elan_i2c
• rmmod elan_i2c

What your security team should do

• Inventory Linux endpoints and appliances that use ELAN I2C touchpad or touchscreen hardware and determine whether the elan_i2c driver is present or loaded.
• Patch affected systems through the normal kernel update process and reboot into the fixed kernel; prioritize portable endpoints and managed images that include ELAN input hardware.
• Verify firmware directories are writable only by trusted administrative paths and are covered by file integrity monitoring or package verification.
• Review golden images, provisioning pipelines, and firmware update repositories for unexpected or manually modified ELAN firmware blobs.
• Add monitoring for kernel oops, KASAN out-of-bounds reports, and elan_i2c firmware load/update errors, especially shortly after boot or driver reloads.
• Treat unexpected changes to firmware blobs as a potential post-compromise or supply-chain indicator, even though this vulnerability has low observed exploitation likelihood and is not currently KEV-listed.