You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
UNCOMPRESS() decompresses zlib payload into untracked memory before length validation, causing memory DoS #70198
The input does not have to be generated by COMPRESS(), so an authenticated SQL user can manually construct a small zlib payload that expands to a very large result.
Example:
SET GLOBAL tidb_mem_quota_query =1073741824;
SELECT @@tidb_mem_quota_query;
SELECT LENGTH(UNCOMPRESS(0x<4-byte-length-header + large-zlib-payload>));
In the reproduced case, the payload was about 1.16 MB but decompressed to 1,200,000,000 bytes.
2. What did you expect to see? (Required)
TiDB should limit and track memory usage during UNCOMPRESS().
If the decompressed output exceeds the declared length or query memory quota, the query should stop instead of continuing to allocate memory.
3. What did you see instead (Required)
TiDB fully decompresses the zlib stream into a bytes.Buffer first, and only checks the declared length after decompression finishes.
The decompression buffer is not tracked by the query memory tracker, so the query can exceed tidb_mem_quota_query.
Observed result:
tidb_mem_quota_query: 1073741824
UNCOMPRESS result length: 1200000000
query succeeded
tidb-server VmHWM increased from ~125 MB to ~2.6 GB
Activity
Debra-He commentedon Jul 29, 2026
/severity moderate
kennedy8312 commentedon Jul 29, 2026
/sig execution
kennedy8312 commentedon Jul 29, 2026
tidb-triage-bot AI rationale
*: fix uncompress mem dos (#70199)
djshow832 commentedon Aug 1, 2026
This is a security bug and blocks the v8.5.8 release, so I'm updating the severity to major.
*: fix uncompress mem dos (#70199) (#70279)