Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-9698

Buffer overflow in extension_based_table_discovery()



    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.0.24
    • 10.0.25, 10.1.13
    • OTHER
    • None
    • Code Inspection / Address Sanitizer + my_alloc.c modifications.
    • 10.1.13


      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.)




            serg Sergei Golubchik
            davidgow David Gow
            0 Vote for this issue
            3 Start watching this issue



              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.