CVE-2026-63908

What it actually does

This is an off-by-one boundary check error in the Linux kernel atmel_mxt_ts touchscreen driver. When the driver parses an Atmel maXTouch configuration file, it is supposed to ignore configuration bytes beyond the known object size. Because the check uses `>` instead of `>=`, one byte at index `mxt_obj_size(object)` is still processed, causing a one-byte overwrite into the adjacent object or instance in the prepared configuration memory. In practical terms, exploitation requires the vulnerable driver to be present and a crafted maXTouch configuration file to be loaded. The likely outcomes are kernel memory corruption, touchscreen/input device malfunction, driver crash, or system instability; reliable privilege escalation is theoretically possible for kernel memory corruption bugs but is not indicated by current public exploitation maturity.

Why it matters to the business

Organizations using Linux-based devices with Atmel maXTouch touchscreen hardware may be exposed to device instability or denial of service if a malformed touchscreen configuration is loaded. The risk is most relevant to embedded systems, kiosks, industrial tablets, appliances, and other Linux devices where touchscreen firmware/configuration updates are performed. This issue is not currently in the CISA KEV catalog, is not associated with ransomware use, has low EPSS, and has no known mature public exploit, so it should generally be prioritized below remotely exploitable internet-facing vulnerabilities unless the affected driver is widely deployed in critical or hard-to-access devices.

How an attack unfolds

An attacker first needs a path to cause the Linux kernel atmel_mxt_ts driver to load a crafted Atmel maXTouch configuration file. This usually implies local administrative access, compromise of a firmware/configuration update process, physical/service access to an embedded device, or supply-chain control over the files delivered to the device. The attacker crafts a configuration object whose declared size is larger than the driver's known object size. During parsing in `mxt_prepare_cfg_mem`, the driver incorrectly allows the first out-of-range byte to be processed. That byte is written past the intended object boundary and corrupts one byte of the adjacent configuration object or instance. Depending on memory layout and subsequent driver behavior, this can result in touchscreen malfunction, a kernel warning or crash, broader system instability, or potentially a more advanced memory-corruption exploit. No active exploitation, ransomware usage, or named threat actor activity is currently indicated by the provided intelligence.

How to fix it

Apply a Linux kernel update that includes the corrected boundary check in the atmel_mxt_ts driver, changing the extra-byte skip condition from `i > mxt_obj_size(object)` to `i >= mxt_obj_size(object)`. If vendor fixed versions are not yet available, track kernel and device-vendor advisories for backported patches affecting `drivers/input/touchscreen/atmel_mxt_ts.c`. As mitigations, disable or remove the `atmel_mxt_ts` driver on systems that do not require Atmel maXTouch touchscreen support, restrict access to touchscreen configuration update mechanisms, prevent untrusted users or management channels from writing firmware/configuration files, and ensure device images only include trusted maXTouch configuration files from controlled release pipelines.

How to confirm the fix worked

Confirm whether the running kernel contains the patched `atmel_mxt_ts` code by checking the kernel package changelog, vendor advisory, or source tree for the corrected `>=` boundary check in `mxt_prepare_cfg_mem`. On source-based or custom kernels, inspect `drivers/input/touchscreen/atmel_mxt_ts.c` and verify the condition skips bytes when `i >= mxt_obj_size(object)`. Confirm whether the module is present or loaded using standard kernel module inventory methods such as `lsmod`, `/proc/modules`, kernel configuration, or device tree/ACPI hardware inventory. Validate exposure by checking whether affected devices use Atmel maXTouch hardware and whether configuration update paths are reachable by non-administrative users or untrusted management workflows. After patching, test normal touchscreen operation and configuration update workflows with known-good configuration files.

Typical attack path

1. Identify a Linux device using the Atmel maXTouch touchscreen driver `atmel_mxt_ts`.
2. Gain the ability to place or trigger loading of a touchscreen configuration file, typically through local administrative access, device management tooling, firmware update workflows, or physical/service access.
3. Create a malformed maXTouch configuration where an object size exceeds the driver's expected `mxt_obj_size(object)`.
4. Trigger the driver configuration loading path so `mxt_prepare_cfg_mem` parses the malicious configuration.
5. Cause a one-byte overwrite into adjacent configuration memory due to the off-by-one boundary check.
6. Leverage the resulting corruption to cause input-device malfunction, denial of service, kernel instability, or potentially a more complex kernel-level exploit if the corruption can be controlled reliably.

How to detect it

Look for evidence that an unexpected or malformed Atmel maXTouch configuration was loaded before touchscreen failure, kernel instability, or device reboot. Useful sources include kernel logs (`dmesg`, journald kernel facility, `/var/log/kern.log`, `/var/log/messages`), firmware/configuration update logs, endpoint file integrity monitoring, package or image deployment logs, and EDR telemetry for processes writing touchscreen configuration files. Investigate recent creation or modification of maXTouch configuration files, especially files named like `maxtouch.cfg` or located in firmware directories. Review administrative activity and device-management actions that triggered touchscreen firmware or configuration updates. In kernel logs, search for `atmel_mxt_ts`, `maXTouch`, configuration update messages, input-device reset failures, kernel oops/panic traces, slab corruption, KASAN reports, or warnings involving `mxt_prepare_cfg_mem`. Because the overwrite is small and occurs inside kernel parsing, there may be no unique network indicator; detection is primarily host- and firmware-update-centric.

• atmel_mxt_ts
• mxt_prepare_cfg_mem
• maxtouch.cfg
• maXTouch
• Atmel maXTouch
• drivers/input/touchscreen/atmel_mxt_ts.c
• update_cfg
• mxt-app
• KASAN: slab-out-of-bounds
• kernel BUG
• Oops
• general protection fault
• BUG: unable to handle kernel paging request

What your security team should do

• Inventory Linux devices and embedded products for Atmel maXTouch touchscreen hardware and the `atmel_mxt_ts` driver.
• Prioritize patching for devices where touchscreen configuration updates can be initiated remotely through management tooling, by local non-admin users, or through field-service workflows.
• Update affected Linux kernels or apply vendor backports that patch `drivers/input/touchscreen/atmel_mxt_ts.c`.
• Restrict write access to firmware and touchscreen configuration directories and ensure only trusted administrators or signed update mechanisms can modify maXTouch configuration files.
• Review device-image, OTA, and firmware-update pipelines to ensure maXTouch configuration files are sourced from trusted repositories and integrity-checked.
• Monitor kernel logs for atmel_mxt_ts errors, touchscreen reinitialization failures, kernel warnings, crashes, or unexpected configuration updates.
• If patching is delayed, disable the driver or block configuration updates on systems that do not require Atmel maXTouch functionality.
• Treat confirmed malicious configuration loading as a potential kernel compromise event and perform full device integrity review, not only driver-level troubleshooting.