GHSA-h599-m3w5-9m7x MariaDB Connector/J: Rogue server can drive large heap allocations from server-declared lengths in OK packets

• Maven org.mariadb.jdbc:mariadb-java-client: >= 3.0.0, < 3.3.7 → fixed in 3.3.7 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.4.0, < 3.4.5 → fixed in 3.4.5 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.5.0, < 3.5.11 → fixed in 3.5.11

Summary MariaDB Connector/J sized heap allocations from lengths declared by the server in OK packets before checking that those lengths fit in the packet. A rogue or MitM server can make the client allocate megabytes from a packet of a few bytes. Details When `CLIENT_SESSION_TRACK` is negotiated (the default), an OK packet carries an info field followed by session-state blocks, each tracked variable being sent as a length-encoded name and value. `OkPacket.parse()` and `parseWithInfo()` allocated `new byte[len]` for the info field, the variable name and the value with the server-declared `len`, then copied the packet data into it. The copy failed with an `ArrayIndexOutOfBoundsException` when the packet was shorter, but only after the allocation had taken place. A server-declared length of 8 MiB in an 18-byte packet was enough to trigger an 8 MiB allocation; the integer-range validation of length-encoded values does not help, since such lengths are valid positive integers. The fix validates every server-declared length against the remaining packet bytes before any allocation (`ReadableByteBuf.checkLength()` and a bounded `readBytes(int)`), and stops reading the session state at the first inconsistent entry. Impact Availability only: a malicious or compromised server, or a MitM, can drive attacker-controlled heap allocations on every OK packet, creating GC pressure up to `OutOfMemoryError` in the client application. Exploitation requires control of the server side of the connection; no authentication bypass, confidentiality or integrity impact. Credit Reported by fg0x0