CVE-2026-99097 in Linux
Summary
by MITRE • 10/26/2026
In the Linux kernel, the following vulnerability has been resolved:
tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper()
tee_dyn_shm_alloc_helper() derives nr_pages from a caller-supplied size and passes it to alloc_pages_exact() without checking it. For size == 0 nr_pages is 0, and alloc_pages_exact(0) calls get_order(0), which is documented as undefined and returns BITS_PER_LONG - PAGE_SHIFT. The page allocator then trips its order > MAX_PAGE_ORDER warning and fails the allocation; on a panic_on_warn kernel that ends the boot.
This can be triggered by TEE_IOC_SHM_ALLOC with struct tee_ioctl_shm_alloc_data where size is 0.
Reject a zero page count, as register_shm_helper() already does for the register path.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The Linux Kernel Trusted Execution Environment subsystem contains a critical input validation flaw within the dynamic shared memory allocation helper function known as tee_dyn_shm_alloc_helper. This vulnerability arises from an insufficient check on user-supplied parameters before they are processed by low-level kernel memory management routines. Specifically, when an application invokes the TEE_IOC_SHM_ALLOC ioctl command with a struct tee_ioctl_shm_alloc_data where the size field is set to zero, the helper function calculates the number of pages required for allocation based directly on this input without verifying that the resulting page count is valid or non-zero. This lack of boundary checking allows an attacker-controlled value to propagate into the kernel's internal memory allocator logic, triggering a sequence of events that can destabilize the system.
The technical root cause lies in how the zero-size request translates through the allocation chain. When size equals zero, the derived number of pages is also zero. The function then calls alloc_pages_exact with this zero value. Internally, alloc_pages_exact invokes get_order to determine the appropriate memory order for the allocation. According to kernel documentation and implementation details, calling get_order on a size that results in zero pages leads to undefined behavior because it effectively computes an invalid page order. On many architectures, this calculation returns BITS_PER_LONG minus PAGE_SHIFT, which typically corresponds to a very large number of orders far exceeding system limits. Consequently, the subsequent call to the page allocator triggers its internal sanity check for maximum allowed page orders. Since the computed order exceeds MAX_PAGE_ORDER, the allocation fails and activates a warning condition within the kernel's debugging infrastructure.
The operational impact of this vulnerability is severe, particularly in environments where kernel warnings are configured to trigger panics rather than mere logging messages. In such configurations, known as panic_on_warn systems often used for security hardening or strict stability requirements, the activation of this warning results in an immediate system crash during boot or runtime operations. This effectively constitutes a local denial-of-service condition that can be triggered by any unprivileged user with access to TEE device nodes. The vulnerability allows a malicious actor to disrupt service availability simply by sending a specifically crafted ioctl request with zero-sized allocation parameters, exploiting the gap between high-level API validation and low-level memory management assumptions.
From a classification perspective, this flaw aligns closely with CWE-20 Improper Input Validation, as the system fails to verify that user input meets expected constraints before processing it within critical subsystem logic. It also relates to CWE-476 NULL Pointer Dereference in spirit, although here the failure manifests through an invalid memory order rather than a direct null pointer access, leading to resource exhaustion or panic conditions. In terms of adversary tactics, this vulnerability supports ATT&CK technique T1053 Scheduled Task/Job, specifically when leveraged during boot sequences to cause system instability, or more broadly under privilege escalation paths where stability is compromised to facilitate further exploitation attempts in complex attack chains involving kernel state manipulation.
To mitigate this risk, the Linux kernel maintainers have implemented a fix that explicitly rejects zero-sized allocations within tee_dyn_shm_alloc_helper. This change brings the dynamic allocation path into alignment with the register_shm_helper function, which already performs similar validation for registered shared memory regions by ensuring that page counts are strictly greater than zero before proceeding with allocation requests. Administrators and developers should ensure their systems are updated to include this patch, as it closes the input validation gap without altering legitimate functionality for valid non-zero allocations. Regular auditing of ioctl handlers in kernel subsystems against CWE-20 standards is recommended to prevent similar oversights where derived values from user inputs bypass essential sanity checks before reaching critical memory management functions.