MariaDB HandlerSocket Improper Request Field-Count Validation Causes Server Crash

How it was found

Product

Product name: MariaDB Server

Product link: https://github.com/MariaDB/server

Affected versions: Reproduced in a locally built test environment based on the official MariaDB source code, running 13.1.0-MariaDB. HandlerSocket is an optional MariaDB plugin. The final affected version range should be confirmed by the vendor.

Summary

HandlerSocket is an optional MariaDB plugin that exposes a separate port for direct table index access similar to key-value queries, bypassing normal SQL parsing to improve performance for simple read/write operations.

When HandlerSocket is enabled, MariaDB accepts client requests through the HandlerSocket port. The exec request contains a "field count" parameter. The code uses that count to allocate stack memory and write field records before checking whether the count is reasonable. An attacker can send an abnormally large field count, causing the mariadbd process to crash and making the database service unavailable.

If HandlerSocket is enabled and handlersocket_plain_secret / handlersocket_plain_secret_wr is not configured, the issue can be triggered by an unauthenticated attacker. If a secret is configured, the attacker must authenticate to HandlerSocket first. The current evidence only proves denial of service. It does not prove code execution or data theft.

Details

A HandlerSocket exec request roughly contains a prepared statement number, operator, field count, and field values. After the affected code reads the client-controlled field count fldnum, it immediately executes logic similar to the following:

fldnum = read_field_count_from_request();
flds = alloca(fldnum * sizeof(string_ref));
for each field:
    flds[i] = string_ref(field_pointer, field_length);

The issue is the validation order. The program should first confirm that fldnum does not exceed the number of fields allowed by the index, and only then allocate memory. Instead, it allocates stack memory based on the client-supplied count and writes into it before the later field-count validation runs.

When an attacker sets the field count to a very large value, the program attempts to allocate an abnormally large stack buffer. In verification, 1000000000 was used as the field count. mariadbd triggered SIGSEGV and exited while writing the first field record.

This is not a normal SQL-port vulnerability. Only deployments that enable the HandlerSocket plugin and expose a HandlerSocket listener are affected. The PoC directory provides a way to build a local test image from the official MariaDB source. The container loads the HandlerSocket plugin and exposes the listener port at startup.

PoC

Reproduction materials are in the poc/ directory:

• poc/README.md
• poc/Dockerfile.mariadb-source
• poc/build-local-image.sh
• poc/run-local-target.sh
• poc/record-poc-demo.sh
• poc/poc.py
• poc/run-poc.sh
• poc/poc.mp4

Reproduction environment:

cd poc
chmod +x *.sh docker-entrypoint-hs.sh
./build-local-image.sh
./run-local-target.sh

By default, the image shallow-clones the official MariaDB repository https://github.com/MariaDB/server.git from the preview-13.1-preview branch and verifies that the current HEAD is fixed at commit 91f37a32f3ee463bdb8287ef951170b5f64201e0. To reproduce against another official source tag or branch, use:

cd poc
MARIADB_REF='<official-tag-or-branch>' MARIADB_EXPECTED_COMMIT='' ./build-local-image.sh
./run-local-target.sh

After the target container starts, it satisfies the following conditions:

1. MariaDB has loaded the HandlerSocket plugin.
2. The HandlerSocket read or write listener port is reachable.
3. Test table hs_verify.t exists, with id as the primary key.
4. If HandlerSocket is configured with a secret, that secret must be passed to the PoC.

Test table:

CREATE DATABASE hs_verify;
CREATE TABLE hs_verify.t (id INT PRIMARY KEY, v VARCHAR(32));
INSERT INTO hs_verify.t VALUES (1, 'one');

Run the PoC:

cd poc
./run-poc.sh --host 127.0.0.1 --port 9998

If HandlerSocket is configured with a secret:

cd poc
./run-poc.sh --host 127.0.0.1 --port 9998 --secret '<secret>'

Key output example:

open response: 0	1
exec response: <empty>
RESULT: VULNERABLE - listener is no longer reachable after trigger

Expected result: HandlerSocket should reject an excessive field count before allocating memory and should keep the MariaDB service running.

Actual result: HandlerSocket accepts the abnormally large field count, the mariadbd process crashes, and the database service becomes unavailable.

poc/poc.mp4 is an end-to-end screen recording. It shows local source-image startup, version and HandlerSocket plugin checks, PoC triggering, container Exited (139) / Segmentation fault crash evidence, and the HandlerSocket port becoming unreachable after the trigger. The recording runs date -R at the end to preserve the reproduction time.

Score

CVSS 3.1 score: 7.5, High.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVSS 3.1 scoring rationale:

• AV:N: The attacker accesses the HandlerSocket listener over the network.
• AC:L: Exploitation is fixed and only requires a normal open request and an abnormal exec request.
• PR:N: When no HandlerSocket secret is configured, no authentication is required before the attack.
• UI:N: No user interaction is required.
• S:U: The impact is limited to the attacked MariaDB service process.
• C:N / I:N: No data disclosure or data tampering has been proven.
• A:H: The issue can crash the mariadbd process and make the database service unavailable.

CWE: CWE-400 (Uncontrolled Resource Consumption)

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab ([email protected])
• Atuin Automated Vulnerability Discovery Engine
• Guannan Wang ([email protected]), Zhanpeng Liu ([email protected]), Jiashuo Liang ([email protected]), Guancheng Li ([email protected])

CVE and credits are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is [email protected].

Note

Note that we follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Impact

An attacker who can access the HandlerSocket port can craft an abnormal request that crashes the MariaDB service process, causing database denial of service.

Impact boundaries:

• Without a HandlerSocket secret: an unauthenticated attacker can trigger the issue.
• With a HandlerSocket secret: the attacker must authenticate to HandlerSocket first.
• The normal SQL port is not affected.
• The current evidence does not prove remote code execution, data disclosure, or data tampering.