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

Server crashes in MDL_key::mdl_key_init (main.lowercase_table4 test fails)

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.0(EOL), 10.1(EOL)
    • 10.0.23, 10.1.9
    • Locking
    • None
    • Windows

    Description

      	mysqld.exe!my_sigabrt_handler(int sig) Line 477	C
      		 
       	mysqld.exe!raise(int signum) Line 593	C
      		 
       	mysqld.exe!abort() Line 82	C
      		 
       	mysqld.exe!_wassert(const wchar_t * expr, const wchar_t * filename, unsigned int lineno) Line 355	C
      		 
       	mysqld.exe!MDL_key::mdl_key_init(MDL_key::enum_mdl_namespace mdl_namespace, const char * db, const char * name) Line 354	C++
      		 
       	mysqld.exe!MDL_request::init(MDL_key::enum_mdl_namespace mdl_namespace, const char * db_arg, const char * name_arg, enum_mdl_type mdl_type_arg, enum_mdl_duration mdl_duration_arg) Line 1244	C++
      		 
       	mysqld.exe!TABLE_LIST::init_one_table(const char * db_name_arg, unsigned __int64 db_length_arg, const char * table_name_arg, unsigned __int64 table_name_length_arg, const char * alias_arg, thr_lock_type lock_type_arg) Line 1702	C++
      		 
       	mysqld.exe!check_fk_parent_table_access(THD * thd, HA_CREATE_INFO * create_info, Alter_info * alter_info) Line 6098	C++
      		 
       	mysqld.exe!mysql_alter_table(THD * thd, char * new_db, char * new_name, HA_CREATE_INFO * create_info, TABLE_LIST * table_list, Alter_info * alter_info, unsigned int order_num, st_order * order, bool ignore) Line 8395	C++
      		 
       	mysqld.exe!Sql_cmd_alter_table::execute(THD * thd) Line 312	C++
      		 
       	mysqld.exe!mysql_execute_command(THD * thd) Line 5107	C++
      		 
       	mysqld.exe!mysql_parse(THD * thd, char * rawbuf, unsigned int length, Parser_state * parser_state) Line 6546	C++
      		 
       	mysqld.exe!dispatch_command(enum_server_command command, THD * thd, char * packet, unsigned int packet_length) Line 1310	C++
      		 
       	mysqld.exe!do_command(THD * thd) Line 998	C++
      		 
       	mysqld.exe!threadpool_process_request(THD * thd) Line 233	C++
      		 
       	mysqld.exe!io_completion_callback(_TP_CALLBACK_INSTANCE * instance, void * context, void * overlapped, unsigned long io_result, unsigned __int64 nbytes, _TP_IO * io) Line 568	C++
      		 
       	kernel32.dll!00000000775832e2()	Unknown

      http://buildbot.askmonty.org/buildbot/builders/win32-debug2/builds/8490/steps/test/logs/stdio

      Attachments

        Issue Links

          blocks

          Task - A task that needs to be done. MDEV-7069 Fix buildbot failures in main server trees

          • Major - Major loss of function.
          • Stalled
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-7186 get_lock() crashes on Windows, main.sp_notembedded and main.trigger_notembedded fail in buildbot

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-28154 parts.alter_table fails on hfs+, Assertion `mdl_namespace_arg == USER_LOCK || ok_for_lower_case_names(db)' failed in MDL_key::mdl_key_init

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            svoj Sergey Vojtovich added a comment - - edited

            elenst, is it something really new? Have you seen anything like this before? And did it really affect 10.0?

            svoj Sergey Vojtovich added a comment - - edited elenst , is it something really new? Have you seen anything like this before? And did it really affect 10.0?
            elenst Elena Stepanova added a comment - - edited

            svoj,
            No, it's not new. Cross-reference report shows that the test has been failing on Windows regularly at least since May, maybe earlier; it's just that it magically escaped all buildbot inspections – we don't check win32-debug2 builder all the time because it's marked experimental, and quite often it can't run tests at all, but still, I looked at it many times since May, I guess it's just bad luck.
            Yes, it really affects 10.0.

            elenst Elena Stepanova added a comment - - edited svoj , No, it's not new. Cross-reference report shows that the test has been failing on Windows regularly at least since May, maybe earlier; it's just that it magically escaped all buildbot inspections – we don't check win32-debug2 builder all the time because it's marked experimental, and quite often it can't run tests at all, but still, I looked at it many times since May, I guess it's just bad luck. Yes, it really affects 10.0.
            svoj Sergey Vojtovich added a comment -

            Looks good, thanks for fixing this! I believe one could bypass security check using this hole. Do you think one can really get access to protected data, or is it just about early error reporting? Reading original bug fix I can imagine it's about the latter (see rev. 0b28d7e048fa097280be54f9baffd202f7626bdd).

            svoj Sergey Vojtovich added a comment - Looks good, thanks for fixing this! I believe one could bypass security check using this hole. Do you think one can really get access to protected data, or is it just about early error reporting? Reading original bug fix I can imagine it's about the latter (see rev. 0b28d7e048fa097280be54f9baffd202f7626bdd).
            wlad Vladislav Vaintroub added a comment -

            Thanks svoj!
            I'm not sure of security hole in this lowercase scenario, my guess is rather no hole here. Whether the database is called TEST or test prior to normalization does not seem important - any of these access checks if succesfull refer to the same database + table, because of case insensitivity, or not?

            wlad Vladislav Vaintroub added a comment - Thanks svoj ! I'm not sure of security hole in this lowercase scenario, my guess is rather no hole here. Whether the database is called TEST or test prior to normalization does not seem important - any of these access checks if succesfull refer to the same database + table, because of case insensitivity, or not?
            svoj Sergey Vojtovich added a comment -

            If there're extra checks before actually referring to a table, then there's no hole indeed.

            svoj Sergey Vojtovich added a comment - If there're extra checks before actually referring to a table, then there's no hole indeed.

            People

              wlad Vladislav Vaintroub
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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