Description

Calling tdelete on a sufficiently deep tree in the GNU C Library version 2.1 to 2.44 may write one pointer past the end of an alloca-allocated array on the stack, which may crash the application. The tdelete implementation keeps an explicit stack of parent nodes for rebalancing, which is grown as needed while descending the tree. Two rebalancing branches push an additional entry without checking the capacity, and write past the array when the stack is exactly full. Triggering this requires a node at a depth of exactly 40 (or 40 plus a multiple of 20), which implies a tree with at least a million nodes, so an attacker must drive a large number of insertions and deletions through an application that uses tsearch and tdelete. The written value is a pointer into a tree node and is not directly attacker controlled. No affected application in common distributions has been identified.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.6",
  "pubDate": "2026-09-14T18:17:46.850Z",
  "pubdate": "2026-09-14T18:17:46.850Z",
  "executiveSummary": "A stack-based buffer overflow vulnerability exists within the tdelete function of the GNU C Library (glibc) versions 2.1 through 2.44.\nThe vulnerability stems from an incorrect bounds check when managing an explicit stack during tree rebalancing operations.\nAn attacker can trigger this condition by manipulating a binary search tree structure to reach a specific depth, causing the application to write a pointer past the end of an alloca-allocated stack array.\nWhile the written value is a memory address and not directly attacker-controlled, the overflow typically results in an application crash, leading to a denial-of-service (DoS) condition.\nThe exploitation requirement involves the management of a significantly large tree, necessitating approximately one million nodes to reach the depth threshold of 40. No specific affected applications have been identified in common distributions, suggesting that while the vulnerability is inherent to the library, successful exploitation requires highly specific application-level data structures.",
  "technicalDetails": "The root cause of this vulnerability is an out-of-bounds write within the tdelete implementation in glibc. The function utilizes an explicit stack of parent nodes to facilitate the rebalancing of tree structures. This stack is allocated on the stack using alloca, a mechanism that allocates memory in the calling function's stack frame.\nDuring the descent and rebalancing process of the tree, the implementation pushes parent nodes onto this stack. The logic fails to verify the remaining capacity of the stack array before executing specific rebalancing branches. In two distinct instances within the rebalancing logic, the implementation pushes an additional entry without bounds checking, leading to an index out-of-bounds condition if the stack is already at maximum capacity.\nTriggering this overflow requires a specific tree depth. A node at a depth of exactly 40, or 40 plus a multiple of 20, is required to hit the overflow threshold. Statistically, this depth is achieved in a balanced tree structure containing at least one million nodes. Consequently, an attacker must successfully manipulate the application into performing a sustained sequence of insertions and deletions to grow the tree to this size.\nOnce the overflow condition is triggered, the implementation writes a pointer to a tree node into the memory address immediately following the alloca-allocated array. Because the pointer value itself is derived from the tree node structure, it is not directly under the control of an attacker, which limits the potential for arbitrary code execution. The primary post-exploitation impact is memory corruption of the stack frame, which reliably causes an application crash, effectively inducing a denial-of-service.\nThe vulnerability does not require authentication or specific privileges beyond the ability to influence the data structures manipulated by tsearch and tdelete. As the operation occurs within the address space of the process, the exposure is local to the application's runtime. There is no network exposure mechanism inherent to the vulnerability itself, meaning the impact is strictly confined to applications that process externally provided input to manage large tsearch-based datasets."
}