CVE-2026-99097

What it actually does

Missing validation of size parameter in tee_dyn_shm_alloc_helper allows a zero value to reach alloc_pages_exact(0), invoking undefined get_order(0) behavior that triggers the page allocator's MAX_PAGE_ORDER warning and allocation failure, potentially panicking the kernel on panic_on_warn configurations.

Why it matters to the business

Systems running affected kernels may experience unexpected crashes or boot failures when unprivileged processes request a zero-length shared memory buffer through the TEE subsystem, leading to downtime and loss of availability for workloads relying on the kernel TEE driver.

How an attack unfolds

An attacker with local access crafts a TEE_IOC_SHM_ALLOC ioctl request supplying a struct tee_ioctl_shm_alloc_data with size set to zero; the kernel path skips the check present in the register path, derives a zero page count, and invokes the allocator, resulting in the warning and possible panic.

How to fix it

Update the Linux kernel to a version containing the upstream fix that rejects zero-sized allocations in tee_dyn_shm_alloc_helper before calling alloc_pages_exact; apply the patch or newer distribution kernel that enforces the same check already present in register_shm_helper.

How to confirm the fix worked

Confirm the fix by inspecting the tee_dyn_shm_alloc_helper source for an explicit zero-page-count rejection prior to the allocator call, or test by attempting a zero-size TEE_IOC_SHM_ALLOC ioctl on a patched kernel and verifying it returns an error without triggering allocator warnings.

Typical attack path

1. Obtain local unprivileged access on a Linux system with the vulnerable TEE driver enabled
2. Open the TEE device node and prepare a tee_ioctl_shm_alloc_data structure with size equal to zero
3. Invoke the TEE_IOC_SHM_ALLOC ioctl
4. Trigger the zero-page allocation path and observe kernel warning or panic

How to detect it

Review kernel logs for page allocator warnings mentioning MAX_PAGE_ORDER or get_order(0) originating from tee shm paths; monitor for unexpected TEE device ioctl activity followed by system instability; no persistent artifacts remain after a successful exploit that does not panic the system.

What your security team should do

• Prioritize kernel updates on systems exposing the TEE driver to untrusted local users
• Audit boot and kernel logs for page allocator order warnings related to tee shm allocations
• Disable the TEE driver if the subsystem is not required for the workload