MariaDB daemon leaks memory with specific query

For every thousand times the following query is run with the provided data dump, the MariaDB daemon leaks ~35M of memory:

SELECT GROUP_CONCAT(`memleak_vtr2`.`language_id` SEPARATOR ',') AS `translation_resources`, `d`.`serialized_c` FROM `memleak_d2` AS `d` LEFT JOIN `memleak_vtr2` ON `d`.`voter_id` = `memleak_vtr2`.`voter_id` GROUP BY `d`.`voter_id` ORDER BY RAND()

If the query keeps getting run, the MariaDB daemon will continue leaking memory until the entire system runs out, well beyond what should be possible through the configured memory limits for MariaDB. The provided query is as close to a minimal case as I can get, but it is reproducible 100% of the time. In particular, I have verified that all of the following must be true for the memory leak to occur:

• the GROUP_CONCAT must be present
• serialized_c must be selected and must be large (multiple kilobytes per row - the original table had COMPRESS()ed data, the provided one is COMPRESS()ed random data of similar length)
• memleak_vtr2 must be an InnoDB table (not MyISAM)
• the GROUP BY must be present
• the ORDER BY must be present
• the ORDER BY must be by RAND()

The amount of memory leaked appears to be proportional to the amount of data in the tables. It is worth noting that there is not a visible change in the MariaDB daemon's memory usage after every individual query execution, it takes multiple queries for that to happen. However, as mentioned before, over a larger number of queries (thousands), the amount of memory leaked is pretty consistent.

Please see the attached data dump and minimal test case for reproduction. Verified on the following MariaDB versions:

5.5.47-1.el7_2 (CentOS 7)
5.5.50-1.el7_2 (CentOS 7)
10.0.26 (Gentoo)
10.1.16 (Gentoo)

Note: memleak.php will report the amount of leaked memory after each run (if any), but relies on assumptions that are probably only true on CentOS 7. Simply check the memory usage manually on other platforms.