[CONJ-932] Login packet has wrong length information for the attributes Created: 2022-02-18  Updated: 2022-03-04  Resolved: 2022-03-04

Status: Closed
Project: MariaDB Connector/J
Component/s: authentication
Affects Version/s: 3.0.2-rc, 3.0.3
Fix Version/s: 3.0.4

Type: Bug Priority: Major
Reporter: Thomas Dai Assignee: Diego Dupin
Resolution: Fixed Votes: 0
Labels: Compatibility, regression
Environment:

Windows 10; Linux


Attachments: PNG File malformed.login.packet.PNG    

 Description   

The latest connector J releases seem have a regression that will set the total length of the attributes part to a very big value, in my test, it was set to 0x FD C4 00 0C, which is 201326788 bytes, but actually it was only about 200 bytes in total. Old releases don't suffer from this issue.

It can be easily seen with a Wireshark net capture, which will annotates the login packet as malformed, see the network capture result attached.



 Comments   
Comment by Diego Dupin [ 2022-02-18 ]

I've reproduced that problem.
It would seems it's an error in wireshark mysql packet decoding.
0xfdc40000 => byte 0xfd indicate that length is 3 bytes little endian encoded 0xc40000 = 196
problem is that wireshark use 4 bytes:
0xc400000c => 201326788

Comment by Diego Dupin [ 2022-02-18 ]

wireshark PR submitted (https://gitlab.com/wireshark/wireshark/-/merge_requests/6239)

Comment by Thomas Dai [ 2022-02-21 ]

Hi Diego, I think it is also something not expected that using 3 bytes to encode an integer when 1 byte is enough? Quoting the MySQL's document here (link: https://dev.mysql.com/doc/internals/en/integer.html):

"An integer that consumes 1, 3, 4, or 9 bytes, depending on its numeric value
To convert a number value into a length-encoded integer:
If the value is < 251, it is stored as a 1-byte integer."

This may break some system that adheres strictly to the above rules. It is possible to fix this on the connector side, too? seems only the new releases suffer from this issue...

Comment by Diego Dupin [ 2022-02-21 ]

I asked myself this question during the implementation and this trick permit some optimization, but allright, predictability/ensure compatibility is a better argument.
It will be part of 3.0.4 release

Comment by Thomas Dai [ 2022-02-22 ]

Thanks Diego!

Generated at Thu Feb 08 03:19:22 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.