CVE-2026-53273

What it actually does

This is a Linux kernel use-after-free race in the OP-TEE TEE driver supplicant request handling path. A client task can be interrupted or exit while a tee-supplicant request is still being processed; the client removes and frees the request while the request ID can remain reachable through the supplicant IDR. A later supplicant receive/send lookup can dereference the freed request, potentially causing kernel memory corruption, kernel crash, or, depending on exploitability on a given platform and kernel build, possible local privilege escalation.

Why it matters to the business

Systems using OP-TEE or Trusted Execution Environment functionality may be exposed to local denial-of-service risk and potentially deeper system compromise if an attacker can run code locally and trigger the race. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no public exploit maturity reported, so it is lower urgency than actively exploited internet-facing flaws; however, kernel memory-safety issues should still be remediated through normal kernel patch cycles because successful exploitation can affect host stability and trust boundaries.

How an attack unfolds

An attacker needs local ability to interact with the Linux TEE/OP-TEE device interface on a system where the OP-TEE driver and supplicant are present. The attacker initiates TEE client requests that are handed to the supplicant, then forces interruption, cancellation, client termination, or timing conditions such that the client exits before the supplicant has completed processing. In the vulnerable race window, the client-side cleanup removes and frees the request while the supplicant still has an identifier that can resolve to the freed object. When the supplicant path later looks up or touches that request, the kernel dereferences freed memory. The most likely observable result is a kernel oops, panic, KASAN report, or service disruption; reliable privilege escalation would require additional heap grooming and platform-specific exploitation work.

How to fix it

Apply a Linux kernel update that includes the OP-TEE supplicant request lifetime fix for this issue. If using vendor kernels, update to the distribution, device vendor, or SoC vendor kernel package that backports the patch. If maintaining a custom kernel, incorporate the upstream fix that serializes access to supplicant requests with supp->mutex in optee_supp_recv() and optee_supp_send(), and updates optee_supp_thrd_req() behavior when the client terminates. Where immediate patching is not possible, reduce exposure by disabling unused OP-TEE/TEE functionality, unloading the OP-TEE driver where operationally safe, restricting access to TEE device nodes, limiting local shell access, and monitoring for kernel crashes involving OP-TEE or tee-supplicant.

How to confirm the fix worked

Confirm the running kernel package or build includes the vendor fix for CVE-2026-53273, not just that source packages were updated. Reboot into the patched kernel and verify with uname, package-manager metadata, vendor advisory status, or kernel changelog entries referencing the OP-TEE supplicant use-after-free fix. On custom builds, confirm the patched OP-TEE driver code holds supp->mutex while looking up and touching supplicant requests in optee_supp_recv() and optee_supp_send(). Validate exposure by checking whether OP-TEE is enabled, whether /dev/tee* devices exist, whether tee-supplicant is installed or running, and whether untrusted users or applications can access the TEE device nodes.

Typical attack path

1. Gain local code execution on a Linux system where OP-TEE/TEE support and tee-supplicant are enabled.
2. Open and interact with the TEE device interface to create supplicant-backed requests.
3. Trigger interruption, process termination, shutdown behavior, or supplicant/client timing races while requests are in flight.
4. Cause the client-side request object to be freed while its request ID remains reachable to the supplicant path.
5. Force the supplicant receive/send path to look up and dereference the stale request pointer.
6. Leverage the resulting use-after-free for a kernel crash, denial of service, or potentially further memory-corruption exploitation.

How to detect it

Retrospective detection should focus on signs of attempted race triggering or successful kernel memory corruption rather than a unique network signature, because exploitation requires local interaction and no specific public exploit indicators are known. Review kernel logs, journalctl, dmesg archives, crash dumps, kdump/vmcore records, KASAN/KFENCE reports, audit logs for access to /dev/tee* devices, and service logs for tee-supplicant failures. Look for kernel oops or panic traces involving OP-TEE supplicant functions such as optee_supp_recv, optee_supp_send, or optee_supp_thrd_req, especially when paired with tee-supplicant restarts, client process termination, or repeated TEE device access by unexpected users. On systems with auditd or EDR telemetry, investigate unusual processes repeatedly opening /dev/tee0 or /dev/teepriv0, high-frequency tee-supplicant interactions, unexplained tee-supplicant crashes, or kernel crashes shortly after TEE device access.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in optee_supp_recv
• use-after-free in optee_supp_send
• optee_supp_recv
• optee_supp_send
• optee_supp_thrd_req
• tee-supplicant
• /usr/sbin/tee-supplicant
• /dev/tee0
• /dev/teepriv0
• optee
• tee: optee
• Unable to handle kernel paging request
• kernel BUG at drivers/tee/optee
• Oops:
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems that use OP-TEE, TEE device nodes, embedded Linux platforms, ARM TrustZone-backed devices, or tee-supplicant.
• Prioritize kernel updates for systems where local users, containers, applications, or third-party workloads can access /dev/tee*.
• Apply vendor kernel fixes and reboot into the corrected kernel during the next appropriate maintenance window.
• Restrict permissions on TEE device nodes to only required service accounts or trusted groups.
• If OP-TEE is not required, disable the OP-TEE driver, remove tee-supplicant, or block module loading where supported.
• Enable collection of kernel logs, crash dumps, audit logs, and service manager logs for systems using tee-supplicant.
• Search historical logs for OP-TEE-related kernel oops, KASAN use-after-free reports, tee-supplicant crashes, or unexplained reboots.
• Treat repeated kernel crashes involving OP-TEE on multi-user systems as potentially suspicious until investigated.