summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMarko Mäkelä <marko.makela@mariadb.com>2017-09-07 12:01:07 +0300
committerMarko Mäkelä <marko.makela@mariadb.com>2017-09-07 12:01:07 +0300
commitd861822c4f5c05dc7a0baa470212c823fc36fe4c (patch)
treeb6d0beaad3b52c98bfae9b60d0c6faa744e8bf99
parentee844f6c346ffa009dda2fcb0588ae430479c71d (diff)
downloadmariadb-git-d861822c4f5c05dc7a0baa470212c823fc36fe4c.tar.gz
MDEV-13253 After rebuilding redo logs, InnoDB can leak data from redo log buffer
recv_reset_logs(): Initialize the redo log buffer, so that no data from the old redo log can be written to the new redo log. This bug has very little impact before MariaDB 10.2. The innodb_log_encrypt option that was introduced in MariaDB 10.1 increases the impact. If the redo log used to be encrypted, and it is being resized and encryption disabled, then previously encrypted data could end up being written to the new redo log in clear text. This resulted in encryption.innodb_encrypt_log test failures in MariaDB 10.2.
-rw-r--r--storage/innobase/log/log0recv.cc1
-rw-r--r--storage/xtradb/log/log0recv.cc1
2 files changed, 2 insertions, 0 deletions
diff --git a/storage/innobase/log/log0recv.cc b/storage/innobase/log/log0recv.cc
index 5180f8b19c0..b99bd582b9a 100644
--- a/storage/innobase/log/log0recv.cc
+++ b/storage/innobase/log/log0recv.cc
@@ -3472,6 +3472,7 @@ recv_reset_logs(
log_sys->archived_lsn = log_sys->lsn;
#endif /* UNIV_LOG_ARCHIVE */
+ memset(log_sys->buf, 0, log_sys->buf_size);
log_block_init(log_sys->buf, log_sys->lsn);
log_block_set_first_rec_group(log_sys->buf, LOG_BLOCK_HDR_SIZE);
diff --git a/storage/xtradb/log/log0recv.cc b/storage/xtradb/log/log0recv.cc
index 0872d231612..2316c35be71 100644
--- a/storage/xtradb/log/log0recv.cc
+++ b/storage/xtradb/log/log0recv.cc
@@ -3574,6 +3574,7 @@ recv_reset_logs(
log_sys->tracked_lsn = log_sys->lsn;
+ memset(log_sys->buf, 0, log_sys->buf_size);
log_block_init(log_sys->buf, log_sys->lsn);
log_block_set_first_rec_group(log_sys->buf, LOG_BLOCK_HDR_SIZE);