COM_BINLOG_DUMP reads binlog position/flags/server_id/filename without checking packet_length (OOB read on short command)

In sql/sql_parse.cc, dispatch_command() handles COM_BINLOG_DUMP by reading a fixed layout from packet without checking that packet_length is large enough:

case COM_BINLOG_DUMP:

  ...

  if (check_global_access(thd, PRIV_COM_BINLOG_DUMP))

    break;

  pos = uint4korr(packet);                 /* needs packet[0..3] */

  flags = uint2korr(packet + 4);           /* needs packet[4..5] */

  if ((thd->variables.server_id= uint4korr(packet+6)))  /* needs packet[6..9] */

    ...

  const char *name= packet + 10;           /* needs at least offset 10 */

  size_t nlen= strlen(name);

do_command() only guarantees a trailing NUL at packet[packet_length] for the full net packet, then calls:

dispatch_command(command, thd, packet+1, (uint)(packet_length-1), ...);

So a client that sends only COM_BINLOG_DUMP (body length 0), or any body shorter than 10 bytes, still reaches the uint4korr / uint2korr / strlen(packet+10) path after privilege check. Those reads go past the owned command body into adjacent net-buffer memory (out-of-bounds read).

Protocol expects at least:

• 4 bytes binlog position
• 2 bytes flags
• 4 bytes server_id
• NUL-terminated filename starting at offset 10

but there is no packet_length >= 10 (or equivalent) guard before parsing.