Hi, Andrei, On Sep 01, Andrei wrote:

revision-id: 489a7fba324 (mariadb-10.5.17-10-g489a7fba324) parent(s): 0324bde8469 author: Andrei committer: Andrei timestamp: 2022-09-01 14:15:11 +0300 message:

MDEV-29322 ASAN heap-use-after-free in Query_log_event::do_apply_event

The ASAN report was reported in the parallel slave execution of a Query event and implicitly involved (so also parallelly run) Format-Description event. The Query actually had dependency on a preceding "old" FD whose instance got destructed, so to cause the ASAN error.

The case is fixed with copying of the value of `options_written_to_bin_log` the sensitive member of FD event into worker's stable placeholders, so FD change won't affect Queries dependent on "old" instances.

The method observes the following properties: 0. each worker gets its private copy; 1. the copied value gets a part of the execution context for any Queries that follow the FD in binlog; 2. any new FD forces a new copy which does not any affect on the past (in binlog order) Queries which might be still in execution.

Sorry, but this doesn't make any sense. The value of options_written_to_bin_log depends on the version of the server that has written that binlog file. Query_log_event cannot just randomly use some options_written_to_bin_log, it must use options_written_to_bin_log from the Format_description_log_event that came from the binlog file where the Query_log_event was read from. If rli->relay_log.description_event_for_exec is not that Format_description_log_event, and assuming that the correct Format_description_log_event is not stored anywhere, the Query_log_event has to remember options_written_to_bin_log itself, there's not much we can do about it. Or it can apply the mask in the constructor and store not flags2 but the new value of thd->variables.option_bits. Or it can extend flags2 to cover all OPTIONS_WRITTEN_TO_BINLOG. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org