BUG#55322: SHOW BINLOG EVENTS increases @@SESSION.MAX_ALLOWED_PACKET

Problem: when SHOW BINLOG EVENTS was issued, it increased the value of
@@session.max_allowed_packet. This allowed a non-root user to increase
the amount of memory used by her thread arbitrarily. Thus, it removes
the bound on the amount of system resources used by a client, so it
presents a security risk (DoS attack).

Fix: it is correct to increase the value of @@session.max_allowed_packet
while executing SHOW BINLOG EVENTS (see BUG 30435). However, the
increase should only be temporary. Thus, the fix is to restore the value
when SHOW BINLOG EVENTS ends.
The value of @@session.max_allowed_packet is also increased in
mysql_binlog_send (i.e., the binlog dump thread). It is not clear if this
can cause any trouble, since normally the client that issues
COM_BINLOG_DUMP will not issue any other commands that would be affected
by the increased value of @@session.max_allowed_packet. However, we
restore the value just in case.


mysql-test/suite/rpl/r/rpl_packet.result:
  update result file
mysql-test/suite/rpl/t/rpl_packet.test:
  Add test that verifies that @@session.max_allowed_packet does not change
  when issuing SHOW BINLOG EVENTS.
  Make previous sub-test clean up.
  Add comments listing the bugs in this test case.
sql/sql_repl.cc:
  Restore the old value of thd->variables.max_allowed_packet at the
  end of mysql_binlog_send and mysql_show_binlog_events.

1 files changed, 38 insertions, 1 deletions

diff --git a/mysql-test/suite/rpl/t/rpl_packet.test b/mysql-test/suite/rpl/t/rpl_packet.test
index bfc144c759b..08a533e22ca 100644
--- a/mysql-test/suite/rpl/t/rpl_packet.test
+++ b/mysql-test/suite/rpl/t/rpl_packet.test
@@ -1,7 +1,12 @@
+# ==== Purpose ====
 #
 # Check replication protocol packet size handling
-# Bug#19402 SQL close to the size of the max_allowed_packet fails on slave
 #
+# ==== Related bugs ====
+# Bug#19402 SQL close to the size of the max_allowed_packet fails on slave
+# BUG#23755: Replicated event larger that max_allowed_packet infinitely re-transmits
+# BUG#42914: No LAST_IO_ERROR for max_allowed_packet errors
+# BUG#55322: SHOW BINLOG EVENTS increases @@SESSION.MAX_ALLOWED_PACKET
 
 # max-out size db name 
 source include/master-slave.inc;
@@ -119,6 +124,38 @@ let $slave_io_running= query_get_value(SHOW SLAVE STATUS, Slave_IO_Running, 1);
 let $last_io_error= query_get_value(SHOW SLAVE STATUS, Last_IO_Error, 1);
 eval SELECT "$last_io_error" AS Last_IO_Error;
 
+# Remove the bad binlog and clear error status on slave.
+STOP SLAVE;
+RESET SLAVE;
+--connection master
+RESET MASTER;
+
+
+#
+# BUG#55322: SHOW BINLOG EVENTS increases @@SESSION.MAX_ALLOWED_PACKET
+#
+# In BUG#55322, @@session.max_allowed_packet increased each time SHOW
+# BINLOG EVENTS was issued. To verify that this bug is fixed, we
+# execute SHOW BINLOG EVENTS twice and check that max_allowed_packet
+# never changes.  We turn off the result log because we don't care
+# about the contents of the binlog.
+
+--disable_result_log
+SET @max_allowed_packet_0= @@session.max_allowed_packet;
+SHOW BINLOG EVENTS;
+SET @max_allowed_packet_1= @@session.max_allowed_packet;
+SHOW BINLOG EVENTS;
+SET @max_allowed_packet_2= @@session.max_allowed_packet;
+--enable_result_log
+if (`SELECT NOT(@max_allowed_packet_0 = @max_allowed_packet_1 AND @max_allowed_packet_1 = @max_allowed_packet_2)`)
+{
+  --echo ERROR: max_allowed_packet changed after executing SHOW BINLOG EVENTS
+  --source include/show_rpl_debug_info.inc
+  SELECT @max_allowed_packet_0, @max_allowed_packet_1, @max_allowed_packet_2;
+  --die @max_allowed_packet changed after executing SHOW BINLOG EVENTS
+}
+
+
 --echo ==== clean up ====
 connection master;
 DROP TABLE t1;