GHSA-797x-p4mc-jwpm: MariaDB Connector/J: Length-encoded integers larger than Integer.MAX_VALUE were truncated before being used as lengths
Summary
MariaDB Connector/J narrowed 8-byte length-encoded integers received from the server to int without validation. A rogue or MitM server can send a value above Integer.MAXVALUE whose truncation becomes a negative or arbitrary length.
Details
The protocol encodes lengths as length-encoded integers, whose 8-byte form the decoder (readLength() and readIntLengthEncodedNotNull()) returned as (int) readLong(). A value above Integer.MAXVALUE therefore wrapped to a negative or unrelated int, used afterwards as a length to size allocations or reads, which ended in NegativeArraySizeException, out-of-bounds exceptions or oversized allocations.
The fix rejects any length-encoded value that does not fit a non-negative int with an explicit error.
Impact
Availability only: a malicious or compromised server, or a MitM, can crash the client's connection handling with unchecked exceptions or drive oversized allocations. Exploitation requires control of the server side of the connection; no authentication bypass, confidentiality or integrity impact.
Credit
Reported by fg0x0
Other sources
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.10, the ReadableByteBuf.readLength() and ReadableByteBuf.readIntLengthEncodedNotNull() methods narrowed the protocol's unsigned 8-byte length-encoded integer to a Java int without checking that the value fit a non-negative integer. Values above Integer.MAXVALUE could wrap to a negative or unrelated length that downstream allocation and read paths used. A malicious or compromised server, or a machine-in-the-middle attacker, could trigger NegativeArraySizeException, out-of-bounds failures, or oversized allocation behavior in client connection handling. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.10.
— OSV
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.5.10 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.4.5 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.3.7 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.3.7 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.4.5 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.5.10
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Applications using MariaDB Connector/J are exposed only when the database server is malicious or compromised, or when an attacker can act as a man-in-the-middle on the connection. The impact is limited to client-side availability.
What does an attacker need to exploit this issue?
The attacker must control the server side of the database connection or be able to modify server responses in transit. No authentication bypass is involved.
What failure modes can indicate exploitation?
Affected clients may show NegativeArraySizeException, out-of-bounds exceptions, or unusually large allocation attempts during connection handling. These result from a server-provided length value being truncated to an invalid int.
What changes in the fixed behavior?
The corrected decoder rejects length-encoded values that cannot fit in a non-negative int and returns an explicit error instead of using the truncated value as a length.