Out-of-bounds read in MariaDB .frm parsing enables RCE via vtable hijacking

How it was found

Summary

MariaDB does not validate the upper bound of the attacker-controlled key_part->fieldnr value parsed from a crafted .frm file before using it as an index into the share->field[] array. The code only verifies that fieldnr is not zero. It does not verify that fieldnr is less than or equal to share->fields. This results in an intra-allocation out-of-bounds read of a Field*pointer. Because share->field and comment_pos are placed in the same multi_alloc_root allocation, an attacker can select an out-of-range fieldnr whose calculated array slot overlaps attacker-controlled data stored at comment_pos.

The attacker-controlled value is subsequently interpreted as a valid Field*. MariaDB then performs a C++ virtual method call through this pointer:

// mariadb-10.4.18/sql/table.cc:2705
// mariadb-11.8.8/sql/table.cc:3162
// mariadb-12.3.2/sql/table.cc:3201
// mariadb-13.1.0/sql/table.cc:3209
if (!key_part->fieldnr)
   goto err;

field = key_part->field = share->field[key_part->fieldnr - 1];

// mariadb-11.8.8/sql/table.cc:3166
// mariadb-12.3.2/sql/table.cc:3205
// mariadb-13.1.0/sql/table.cc:3213
if (Charset::collation_changed_order(share->mysql_version, field->charset()->number))

// mariadb-10.4.18/sql/table.cc:2709
key_part->type = field->key_type();

This allows the attacker to supply a forged C++ object and fake vtable. The virtual call dereferences the attacker-controlled vtable and results in control-flow hijacking. In my tested environment, this behavior was successfully used to achieve arbitrary code execution in the security context of the MariaDB server process.

Attack prerequisites

The proof of concept was tested under the following conditions:

1. The attacker has an authenticated SQL session.
2. The SQL account has the global FILE privilege.
3. secure_file_priv is unset or configured as an empty string, allowing file operations in locations accessible to the MariaDB server process.
4. The MariaDB operating-system account can create files inside the database data directory.
5. The attacker can cause MariaDB to load the crafted .frm metadata.

The attack does not require an existing operating-system shell or direct filesystem access. The crafted .frm file is delivered through the SQL interface using the FILE privilege. In the tested environment, the MariaDB operating-system account could write to the data directory but could not write to the plugin directory or other executable/library directories.

Security boundary

The FILE privilege permits specific SQL file operations, but it does not grant permission to execute arbitrary native code or control C++ virtual function dispatch. Additionally, SELECT ... INTO DUMPFILE/OUTFILE cannot overwrite an existing file. The attacker is limited to creating a new file in a location writable by the MariaDB server process. This vulnerability converts the ability to create a data or metadata file inside the MariaDB data directory into arbitrary code execution inside the MariaDB server process. Therefore, the impact exceeds the intended capabilities of the FILE privilege.

Affected versions

The vulnerability was reproduced on:

• MariaDB 10.4.18
• MariaDB 11.8.8
• MariaDB 12.3.2
• MariaDB 13.1.0 Preview
• Other versions have not yet been fully tested (to RCE) but based on the memory allocation structure and processing methods, it is expected that most versions will be affected by this vulnerability if there is no control over fieldnr oob.

Result

Successful exploitation provides arbitrary code execution with the operating-system privileges of the mariadbd process. This is an authenticated remote code execution vulnerability when the SQL service is reachable over the network and the attacker possesses the required database privileges.

Impact

An authenticated attacker with the MariaDB FILE privilege can convert the ability to create a file in the MariaDB data directory into arbitrary native code execution inside the mariadbd process.

The vulnerability allows the attacker to:

• Perform an out-of-bounds read from the share->field[] pointer array
• Substitute an attacker-controlled pointer for a legitimate Field*
• Supply a forged C++ object and fake vtable
• Control the target of a C++ virtual function call
• Execute arbitrary code with the operating-system privileges of the MariaDB server process

This impact is greater than the intended capability of the FILE privilege.

In the tested environment, the attacker could write only to the MariaDB data directory. The attacker could not write to the plugin directory, system library directories, or executable directories and did not have an existing operating-system shell. Without this vulnerability, creating a new database metadata file does not authorize the SQL user to execute native code. The vulnerability crosses that boundary by causing MariaDB to interpret attacker-controlled metadata bytes as a C++ object and invoke a virtual method through an attacker-controlled vtable.

Successful exploitation may allow the attacker to:

• Read or modify data accessible to the MariaDB operating-system account
• Bypass SQL-level authorization checks by operating inside the server process
• Modify or delete files writable by the MariaDB operating-system account
• Access credentials, keys, configuration, or process memory available to mariadbd
• Establish outbound network connections from the database server
• Terminate or corrupt the database server process
• Cause complete loss of database confidentiality, integrity, and availability within the privileges of the MariaDB service account

The vulnerability does not inherently provide root privileges. The final operating-system impact remains limited by the privileges of the mariadbd account and any active controls such as SELinux, AppArmor, containers, or systemd sandboxing. The issue was successfully reproduced as arbitrary code execution on MariaDB 10.4.18, 11.8.8, 12.3.2 and MariaDB 13.1.0 Preview.