The call to my_strnncoll in extension_based_table_discovery() (in sql/discover.cc) accepts 'len' as the length of both 'from->name' and 'cur->name', however it is possible that 'from->name' is shorter than 'len', potentially leading to a buffer overflow. This usually goes unnoticed, but ASAN will pick up on it (during many tests, including rpl.rpl_drop_db) if the valgrind paths in my_alloc.c are enabled.

We are fixing this locally (see attached patch) by calculating an additional 'from_len', and passing this to the my_strnncoll function. This should also remove the need for the extra comparison of 'from->name[len]', as my_strnncoll, when passed the right lengths, should properly handle the case where the first 'len' bytes of 'cur->name' is a prefix of 'from->name'. (Note that this would change the behaviour slightly in the case where 'from->name' has no extension.)

(As a heads-up: the way extensions/partitions are handled for extension_based_table_discovery() does not actually match the comment at the top of the function. For example, filenames are compared up to the last '#' (if it is not the first character of the filename), not the first. I haven't looked into this further (as to which behavior is correct) so it may be a different bug.)