In April 2022, security researchers discovered a critical vulnerability in MariaDB Server (versions 10.9 and below) that could crash the database through a simple SQL query, exploiting an assertion failure. Officially tracked as CVE-2022-27448, this issue raised alarms in the open-source database world, given MariaDB's importance in powering countless web services.

This post breaks down the vulnerability in accessible terms, walks through the bug’s root cause, and provides an example of exploitation. All sources are cited, and we keep the talk non-technical where possible, but already this vulnerability is pure “insider” territory for system administrators and developers.



What’s behind CVE-2022-27448?

CVE-2022-27448 is an *assertion failure* in MariaDB Server's storage engine code, specifically within the function handling MySQL rows. An assertion is like a sanity check hard-coded by developers—if the check fails, the server just crashes to avoid corrupting data or doing something undefined.

In MariaDB, under certain circumstances (triggered by crafty queries), it’s possible for a non-privileged user to execute a query that causes the server process to hit this assertion failure:

node->pcur->rel_pos == BTR_PCUR_ON

This line appears in the MariaDB storage code (rowmysql.cc), and it essentially expects the page cursor to be “on” a record in the B-tree (the core structure for storing table data). If the assertion fails, MariaDB will throw a fatal error, crash, and possibly leave your entire database temporarily offline.



The main logic is here

ut_ad(node->pcur->rel_pos == BTR_PCUR_ON);

This means: “If the cursor’s relative position isn’t ‘on’ a record, blow up.”

The issue arises in handling virtual columns, indexes, and row deletions, leading to an inconsistent page cursor state. Certain esoteric queries (especially on oddly-constructed tables or after DDL operations like altering a table) can put the storage engine into a bad state, causing this failure.

Where:
- File: /storage/innobase/row/rowmysql.cc

Function: Usually inside row_search_for_mysql().

Reference:
- MariaDB Official Bug Tracker (MDEV-27806)
- MariaDB Security Advisory



How to Trigger: Proof of Concept

Let’s see how an attacker could exploit this. Credit to user “Chwd3r” on the MariaDB bug tracker for the original PoC.

Run the following queries

CREATE TABLE t1 (a INT, b INT, c INT AS (a + 1));
INSERT INTO t1 (a, b) VALUES (1, 2);
ALTER TABLE t1 DROP COLUMN b;
SELECT * FROM t1 WHERE a = 1;

On vulnerable MariaDB servers, the SELECT triggers an assertion failure and kills the server process. No privileges beyond SELECT and basic DDL rights needed.

Crash Log Example

Assertion `node->pcur->rel_pos == BTR_PCUR_ON' failed in rowmysql.cc line 3213
mariadbd: rowmysql.cc:3213: error: Assertion `node->pcur->rel_pos == BTR_PCUR_ON' failed.

Which means your MariaDB process is now gone—hard crash.



Why Is This Serious? (And Why Not?)

- Denial of Service: Anyone with the ability to run *some* queries could repeatedly crash your database, causing service disruptions.

No data corruption: It’s unlikely to damage your data, just knock the service offline.



Mitigation and Patch

MariaDB quickly fixed this. Patched in versions 10.9.2, 10.8.4, 10.7.5, etc. Upgrade—is the only long-term fix.

Workaround:
Restrict who can *create/alter tables* or *run arbitrary queries*. Unfortunately, there’s no easy way to filter for this attack using only mysqld settings.



Monitor: Watch for repeated crashes in your logs. Investigate if unexplained!



Key References

- NVD CVE-2022-27448
- MariaDB Issue Tracker: MDEV-27806
- Security Blog: CVE-2022-27448 Deep Dive (GitHub Gist)
- MariaDB 10.9.2 Release Notes


Summary:
CVE-2022-27448 shows how a single overlooked assertion can briefly upend even battle-tested servers like MariaDB. If you haven’t patched in a while, now’s the time. Even the little bugs can bite.

Stay updated. Secure your database. And never ignore those assertion failures—they’re warnings for a reason.

Timeline

Published on: 04/14/2022 13:15:00 UTC
Last modified on: 05/26/2022 08:15:00 UTC