CVE-2026-53273 Overview
CVE-2026-53273 is a use-after-free vulnerability in the Linux kernel's OP-TEE (Open Portable Trusted Execution Environment) driver. The flaw resides in the tee/optee supplicant request handling path. A previous commit (70b0d6b0a199) made client waits killable, allowing the client task to terminate while the supplicant continues processing its request. When the client exits first, it removes the request from its queue and calls kfree() on it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory.
Critical Impact
Local attackers with the ability to trigger supplicant requests on systems using OP-TEE may exploit this race condition to corrupt kernel memory, potentially leading to privilege escalation or denial of service.
Affected Products
- Linux kernel versions containing commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") prior to the patched releases
- Systems using the OP-TEE driver (drivers/tee/optee) for Trusted Execution Environment support
- Embedded and ARM-based Linux distributions leveraging OP-TEE for secure world communication
Discovery Timeline
- 2026-06-25 - CVE-2026-53273 published to NVD
- 2026-06-25 - Last updated in NVD database
Technical Details for CVE-2026-53273
Vulnerability Analysis
The vulnerability is a classic use-after-free [CWE-416] race condition in the OP-TEE supplicant communication path. The OP-TEE driver mediates requests between user-space clients and a supplicant process that services calls from the secure world. Client tasks submit requests, then wait for the supplicant to process and return results.
Commit 70b0d6b0a199 changed the client wait to a killable wait so it can be interrupted during shutdown or after a supplicant crash. This changed the lifetime expectations of the request object. The client task can now terminate while the supplicant still holds a reference to the request via supp->idr.
When the client exits early, it dequeues the request and frees it with kfree(). The request ID, however, remains registered in the IDR (ID Radix) table. The supplicant's subsequent lookup in optee_supp_recv() or optee_supp_send() retrieves a dangling pointer and dereferences freed kernel memory.
Root Cause
The root cause is unsynchronized access to the request object shared between the client and supplicant threads. The change from an uninterruptible wait to a killable wait introduced a new termination path that was not coordinated with the supplicant's IDR-based lookup. No mutex protected the request object during teardown, allowing the request to be freed while still reachable via the supplicant's IDR.
Attack Vector
A local user able to invoke OP-TEE operations can race the client termination against supplicant servicing. By killing the client task while a request is in flight, an attacker triggers the freeing of the request structure while the supplicant still references it via supp->idr. The fix serialises access using supp->mutex, held in both optee_supp_recv() and optee_supp_send() during lookup, and ensures optee_supp_thrd_req() signals optee_supp_send() when the client has terminated.
No public exploit code is available. See the Linux Kernel Commit 9a0dc92 for the patch implementation details.
Detection Methods for CVE-2026-53273
Indicators of Compromise
- Kernel oops or panic messages referencing optee_supp_recv, optee_supp_send, or optee_supp_thrd_req in dmesg output
- KASAN (Kernel Address Sanitizer) reports flagging use-after-free in the drivers/tee/optee/supplicant.c code path
- Unexpected termination of OP-TEE client processes coinciding with supplicant errors
Detection Strategies
- Enable KASAN on test and staging kernels to surface use-after-free conditions in the OP-TEE supplicant path
- Monitor kernel log streams for crashes or warnings originating from OP-TEE supplicant functions
- Audit running kernel versions against the patched commits to identify unpatched systems
Monitoring Recommendations
- Forward dmesg and /var/log/kern.log to a central log aggregator for anomaly detection
- Track abnormal termination patterns of OP-TEE client processes against supplicant activity
- Establish alerting on kernel module crashes within the tee subsystem on production hosts
How to Mitigate CVE-2026-53273
Immediate Actions Required
- Inventory all Linux systems that load the optee kernel module and identify those exposed to local users
- Apply the upstream stable kernel patches that introduce supp->mutex serialisation in the OP-TEE supplicant path
- Restrict access to the OP-TEE device nodes (typically /dev/tee* and /dev/teepriv*) to trusted users only via filesystem permissions
Patch Information
The fix serialises access to OP-TEE supplicant requests by holding supp->mutex during lookups in optee_supp_recv() and optee_supp_send(), and by signalling optee_supp_send() when the client task has terminated. The patches are available in multiple stable kernel branches via the following commits: 373152c, 387a926, 416259c, 724d0ca, 9a0dc92, ae847ab, d366a01, and d5b57bb.
Workarounds
- Unload the optee kernel module on systems that do not actively require Trusted Execution Environment support
- Tighten permissions on OP-TEE device nodes to limit which local users can submit requests to the supplicant
- Reduce the local attack surface by restricting shell access on embedded devices and ARM platforms where OP-TEE is in use
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
