CVE-2022-47015 Overview
CVE-2022-47015 is a Null Pointer Dereference vulnerability affecting MariaDB Server versions before 10.3.34 through 10.9.3. The vulnerability exists in the spider_db_mbase::print_warnings function within the Spider storage engine, where it is possible to dereference a null pointer, leading to a Denial of Service (DoS) condition. An authenticated attacker with network access can exploit this flaw to crash the database server, disrupting critical database operations and availability.
Critical Impact
Authenticated attackers can crash MariaDB Server instances by triggering a null pointer dereference in the Spider storage engine, causing service disruption for all connected applications and users.
Affected Products
- MariaDB Server versions 10.3.x before 10.3.34
- MariaDB Server versions 10.4.x through 10.9.x before 10.9.3
- MariaDB Server with Spider storage engine enabled
Discovery Timeline
- 2023-01-20 - CVE-2022-47015 published to NVD
- 2025-04-03 - Last updated in NVD database
Technical Details for CVE-2022-47015
Vulnerability Analysis
This vulnerability is classified as CWE-476 (NULL Pointer Dereference) and resides within the Spider storage engine component of MariaDB Server. The Spider storage engine enables federated database functionality, allowing MariaDB to distribute tables across multiple servers.
The vulnerable function spider_db_mbase::print_warnings fails to properly validate pointer references before dereferencing them. When specific conditions are met during query execution that triggers warning logging, the function attempts to access memory through an unvalidated pointer. If this pointer is null, the operation causes an immediate crash of the database server process.
The vulnerability is particularly concerning because it can be triggered by an authenticated user with low privileges through normal database operations that generate warnings within the Spider storage engine context.
Root Cause
The root cause lies in insufficient null pointer validation within the spider_db_mbase::print_warnings function located in storage/spider/spd_db_mysql.cc. When the Spider storage engine attempts to log result warnings (controlled by the spider_param_log_result_errors() parameter), the code directly calls print_warnings() without ensuring that all required data structures and pointers have been properly initialized.
The fix, tracked as MDEV-29644, refactors the warning handling logic by replacing the vulnerable print_warnings() function with a safer fetch_and_print_warnings() implementation that includes proper validation.
Attack Vector
The attack vector is network-based and requires authentication with low privileges. An attacker must have valid credentials to connect to the MariaDB server and the ability to execute queries that interact with tables using the Spider storage engine. The attack does not require user interaction and can be reliably reproduced.
To exploit this vulnerability, an attacker would:
- Authenticate to the MariaDB server with valid credentials
- Execute queries against Spider-managed tables that trigger warning conditions
- When the warning logging threshold is met (log_result_errors >= 3), the vulnerable code path is triggered
- The null pointer dereference crashes the database server
The following patch demonstrates how MariaDB addressed the vulnerability in storage/spider/spd_db_mysql.cc:
db_conn->affected_rows, db_conn->insert_id,
db_conn->server_status, db_conn->warning_count);
if (spider_param_log_result_errors() >= 3)
- print_warnings(l_time);
+ fetch_and_print_warnings(l_time);
} else if (log_result_errors >= 4)
{
time_t cur_time = (time_t) time((time_t*) 0);
Source: GitHub Commit Details
The corresponding header file change in storage/spider/spd_db_mysql.h:
bool is_xa_nota_error(
int error_num
);
- void print_warnings(
- struct tm *l_time
- );
+ void fetch_and_print_warnings(struct tm *l_time);
spider_db_result *store_result(
spider_db_result_buffer **spider_res_buf,
st_spider_db_request_key *request_key,
Source: GitHub Commit Details
Detection Methods for CVE-2022-47015
Indicators of Compromise
- Unexpected MariaDB server crashes with segmentation fault errors in system logs
- Core dumps referencing spider_db_mbase::print_warnings or Spider storage engine functions
- Repeated database service restarts without apparent cause when Spider engine tables are accessed
- Error logs showing null pointer dereference exceptions in the MariaDB error log
Detection Strategies
- Monitor system logs for MariaDB process crashes with signals indicating memory access violations (SIGSEGV)
- Implement database query auditing to identify unusual query patterns against Spider engine tables
- Deploy application-level monitoring to detect database connection failures and timeouts
- Review MariaDB error logs for references to Spider storage engine failures
Monitoring Recommendations
- Configure alerting for MariaDB service availability and unexpected restarts
- Implement health checks that verify database responsiveness at regular intervals
- Monitor system resource utilization for signs of DoS attempts
- Enable detailed Spider storage engine logging during investigation periods
How to Mitigate CVE-2022-47015
Immediate Actions Required
- Upgrade MariaDB Server to version 10.3.34 or later (for 10.3.x branch) or 10.9.3 or later (for other affected branches)
- Review and restrict database user privileges, limiting access to Spider storage engine tables
- Implement network segmentation to limit database access to trusted application servers only
- Enable enhanced logging to detect potential exploitation attempts
Patch Information
MariaDB has released patched versions that address this vulnerability. The fix is available in MariaDB Server versions 10.3.34 and later across all affected branches. The patch replaces the vulnerable print_warnings() function with a safer fetch_and_print_warnings() implementation that properly handles null pointer scenarios.
The specific commit implementing the fix can be reviewed at the GitHub Commit Details. Additional security advisories have been published by Debian, Fedora, and NetApp.
Workarounds
- Disable the Spider storage engine if not required by removing or commenting out the plugin configuration
- Reduce the spider_log_result_errors parameter to below 3 to avoid triggering the vulnerable code path
- Implement strict access controls to limit which users can execute queries against Spider engine tables
- Deploy a database proxy or firewall to filter potentially malicious queries
# Configuration example
# Disable Spider storage engine in MariaDB configuration
# Add to /etc/mysql/mariadb.conf.d/50-server.cnf or my.cnf
[mariadbd]
# Disable Spider storage engine plugin
skip-spider
# Alternatively, reduce log verbosity to avoid vulnerable code path
# spider_log_result_errors=2
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


