CVE-2023-52969 - Deep Dive into the MariaDB "Empty Backtrace" Crash Vulnerability

In 2023, the MariaDB project became aware of a troubling bug now tracked as CVE-2023-52969. This bug, affecting MariaDB Server versions 10.4–10.5.*, 10.6–10.6.*, 10.7–10.11.*, and 11.–11..*, can lead to a server crash, with a notably strange effect: the crash log’s stack trace will be empty. This makes debugging and forensics much harder for administrators and developers alike.

Useful references

If you’re running MariaDB, this is a real-world vulnerability you shouldn’t ignore.

The Crash with No Clues

While most MariaDB crashes throw a wealth of information—including a stack trace (so developers can see which function failed)—this bug results in MariaDB stopping unexpectedly and logs that are missing the stack trace. The behavior centers around the MariaDB optimizer, especially in processes dealing with aggregated tables, like make_aggr_tables_info and optimize_stage2.

11. — all releases

The bug has been fixed in later versions; if you’re using any of these, you should upgrade.

How to Trigger CVE-2023-52969 (Example)

The vulnerability is tied to the query planner/optimizer. To trigger the crash, you need a maliciously or curiously crafted query involving aggregation and possibly malformed table metadata.

Below is a simplified example (for illustration, not guaranteed to crash every version)

-- Assume a table with specific aggregation needs
CREATE TABLE sales (
  id INT PRIMARY KEY,
  region VARCHAR(10),
  total INT
);

-- This query may cause problems, especially with malformed or missing data
SELECT region, SUM(TOTAL)
FROM sales
WHERE region IS NULL
GROUP BY region
HAVING SUM(TOTAL) > 
ORDER BY (SELECT NULL);

-- The inner ORDER BY or subselect may interact with the optimizer in unexpected ways

Important: In the real-world bug, the crash is more likely triggered by crafted or buggy views, subqueries, or by modifying table definitions while running heavy analytics. Most users won’t run into this, but attackers or automated query generators might.

Technical Details

The publicly available MariaDB JIRA ticket (MDEV-32170) references empty crash logs, particularly calling out these functions:

make_aggr_tables_info: Sets up structures to optimize aggregation queries.

- optimize_stage2: Second-stage optimization—decides how to distribute and order work for efficient execution.

Trips a logic flaw that causes the stack trace generation to skip or fail

This means logging is incomplete. For security teams or DBAs, that’s a worst-case scenario.

No direct data leakage: But with no crash logs, adversaries might use this to hide or distract.

- Real availability impact: Your database might go down by accident, or by intent via crafted queries.

Restrict or audit applications that generate user-defined aggregation queries.

- Regularly restart MariaDB to clear corrupted/plagued internal state (not a true fix).

Here’s a basic Bash script to check your MariaDB logs for empty backtrace crashes

#!/bin/bash

LOGFILE="/var/log/mysql/error.log"
grep -A 10 "mysqld got signal" "$LOGFILE" | grep -q "backtrace:" && echo "Stack trace found" || echo "ALERT: Empty backtrace crash detected!"

References

- CVE-2023-52969 at NIST NVD
- MariaDB Security Announcements
- MariaDB JIRA: MDEV-32170
- MariaDB Download & Upgrades

Summary

The MariaDB bug tracked as CVE-2023-52969 might seem simple—a crash with a missing stack trace—but leaves doors wide open for denial-of-service attacks and weakens security monitoring. If you use MariaDB, you should act now: upgrade to patched versions, and examine your logs for unusual crashes.

Understanding the internals (like how aggregation queries are planned) can help you avoid or spot problems, while proper patching is your main defense.

Stay safe, and keep those databases running strong!

Timeline

Published on: 03/08/2025 23:15:14 UTC