Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.6(EOL), 13.1
-
Can result in hang or crash
-
Fix crash on Format Description event with incomplete contents
-
Q3/2026 Replic. Development
Description
- CWE-131 Incorrect Calculation of Buffer Size → CWE-191 Integer Underflow → CWE-126 Buffer Over-read → …
- Originally reported by Tristan Madani
Root Mistake
The binary-parsing Format Description Event constructor has a guard for insufficient data:
if (event_len < LOG_EVENT_MINIMAL_HEADER_LEN + ST_COMMON_HEADER_LEN_OFFSET) |
But this guard does not match the subsequent parsing steps, which read fixed-sized memory up to common_header_len inclusive.
The guard should be … + (ST_COMMON_HEADER_LEN_OFFSET + sizeof(common_header_len)).
In hypothetical words, the first non-fixed-size field is post_header_len, so the guard should be … + ST_POST_HEADER_LEN_OFFSET.
Effect
If the event has a length of exactly LOG_EVENT_MINIMAL_HEADER_LEN + ST_COMMON_HEADER_LEN_OFFSET, the guard will pass, but the parser will read 256 bytes beyond the event buffer:
- The 0-indexed byte LOG_EVENT_MINIMAL_HEADER_LEN + ST_COMMON_HEADER_LEN_OFFSET for the common_header_len field
- event_len - (LOG_EVENT_MINIMAL_HEADER_LEN + ST_COMMON_HEADER_LEN_OFFSET + 1) = -1 number of post_header_len lengths, which in uint8 arithmetic means 255 more bytes after common_header_len.
- If the Format Description's server version supports checksumming, then the algorithm is fetched and removed from the last byte of the post_header_len array.
The consequence is that common_header_len, post_header_len and the checksum algorithm are all loaded from unknown heap data.
Cascade Effect
The Format Description plays a critical role in determining field offsets for ALL subsequent event constructors from its post_header_len array and common_header_len fields.
Corrupted header lengths will most likely instruct subsequent event parsers to read their body data at incorrect locations, possibly beyond their event buffers.
This means the impact is not just OOB reads: parsing corruption can lead to a wide range of misbehaviours, most likely a crash.
An opening for RCE is also possible if the binlog data happens to line up just right, though attack vectors (rogue replication source, MITM on unencrypted replication, crafted binlog files) could have directly injected Query events for ACE instead of engineering such through corrupted Format Descriptions.)
Reproduction
Craft a Format Description Event with a length of 75 (checksum length extra):
- 19-byte common header (LOG_EVENT_MINIMAL_HEADER_LEN)
- 56-byte post-header (ST_COMMON_HEADER_LEN_OFFSET)
- No room for common_header_len byte, post_header_len array, or the checksum algorithm
ASan will trip in the Format Description parser constructor.
Attachments
Issue Links
- relates to
-
MDEV-40647 Replication Breaks from Mal-copied Binlog Name on Malformed Format_description Event
-
- Closed
-
-
MDEV-40760 Lift the runtime dependency on the current Format Description event
-
- Open
-
-
MDEV-39485 Heap-buffer-overflow in mariadb-binlog upon read in Rows_log_event constructor in sql/log_event.cc
-
- Closed
-
- split to
-
MDEV-40366 OOB read for used_checksum_alg on malformed Format_description_log_event
-
- Closed
-