1. 09 Apr, 2018 2 commits
    • Ajo Robert's avatar
      Bug#27197235 USER VARIABLE + UINON + DECIMAL COLUMN RETURNS · 940b88b6
      Ajo Robert authored
                                WRONG VALUES
      
      User variables will have the default session collation
      associated with it. And a select which uses it as part of a
      union may infer the collation while type merging.
      This leads to problems when the result is of DECIMAL type.
      Setting the appropriate collation of DECIMAL result type
      is missing in 5.7 code base.
      
      Added code to set appropriate collation when the result is
      of DECIMAL type during Item_type_holder::join_types().
      940b88b6
    • Arun Kuruvila's avatar
      Bug#27510150: MYSQLDUMP FAILS FOR SPECIFIC --WHERE CLAUSES · d982e717
      Arun Kuruvila authored
      Description: Mysqldump utility fails for specific clauses
      used with the option, 'where'.
      
      Analysis:- Method, "fix_identifier_with_newline()" that
      prefixes all occurrences of newline char ('\n') in incoming
      buffer does not verify the size of the buffer. The buffer in
      which the incoming buffer is copied is limited to 2048 bytes
      and the method does not try to allocate additional memory
      for larger incoming buffers.
      
      Fix:- Method, "fix_identifier_with_newline()" is modified
      to fix this issue.
      d982e717
  2. 26 Feb, 2018 2 commits
    • Balasubramanian Kandasamy's avatar
      b7aafca7
    • Nisha Gopalakrishnan's avatar
      BUG#27216817: INNODB: FAILING ASSERTION: · c0b4d74b
      Nisha Gopalakrishnan authored
                    PREBUILT->TABLE->N_MYSQL_HANDLES_OPENED == 1
      
      ANALYSIS:
      =========
      
      Adding unique index to a InnoDB table which is locked as
      mutliple instances may trigger an InnoDB assert.
      
      When we add a primary key or an unique index, we need to
      drop the original table and rebuild all indexes. InnoDB
      expects that only the instance of the table that is being
      rebuilt, is open during the process. In the current
      scenario we have opened multiple instances of the table.
      This triggers an assert during table rebuild.
      'Locked_tables_list' encapsulates a list of all
      instances of tables locked by LOCK TABLES statement.
      
      FIX:
      ===
      We are now temporarily closing all the instances of the
      table except the one which is being altered and later
      reopen them via Locked_tables_list::reopen_tables().
      c0b4d74b
  3. 23 Feb, 2018 1 commit
  4. 14 Feb, 2018 1 commit
  5. 12 Feb, 2018 1 commit
    • Arun Kuruvila's avatar
      Bug#25471090: MYSQL USE AFTER FREE · e4784703
      Arun Kuruvila authored
      Description:- Mysql client crashes when trying to connect
      to a fake server which is sending incorrect packets.
      
      Analysis:- Mysql client crashes when it tries to read
      server version details.
      
      Fix:- A check is added in "red_one_row()".
      e4784703
  6. 09 Feb, 2018 1 commit
    • Pavan Naik's avatar
      BUG#27448061: MYSQLD--DEFAULTS-FILE TEST FAILS FOR NDB RELEASES · e585decb
      Pavan Naik authored
                    PREVIOUS TO MYSQL 8.0
      
      Description :
      -------------
      The mysqld--defaults-file test fails when the test suite is run from a
      non-canonical path, which happens when the current working directory
      when mysql-test-run.pl is started contains a symbolic link.
      
      The problem is that this test case uses --replace-result with
      $MYSQL_TEST_DIR. This variable is a potentially non-canonical path
      based on the current working directory when mtr is started. However,
      the path in the expected error message from mysqld contains a
      canonical path. This means it does not contain $MYSQL_TEST_DIR if
      mtr's working directory is not the canonical path of the working
      directory.
      
      Because other tests produce output that may contain non-canonical
      paths, making $MYSQL_TEST_DIR always canonical is not a fix.
      
      Fix :
      -----
      Introduced a new environment variable '$ABS_MYSQL_TEST_DIR' which will
      contin the canonical path to the test directory and replaced
      $MYSQL_TEST_DIR with the new variable in main.mysqld--defaults-file
      test file.
      
      This is a back-port of BUG#24579973.
      
      Change-Id: I3b8df6f2d7ce2b04e188a896d76250cc1addbbc1
      e585decb
  7. 02 Feb, 2018 1 commit
    • Joao Gramacho's avatar
      BUG#24365972 BINLOG DECODING ISN'T RESILIENT TO CORRUPT BINLOG FILES · 3fb2f8db
      Joao Gramacho authored
      Problem
      =======
      
      When facing decoding of corrupt binary log files, server may misbehave
      without detecting the events corruption.
      
      This patch makes MySQL server more resilient to binary log decoding.
      
      Fixes for events de-serialization and apply
      ===========================================
      
      @sql/log_event.cc
      
      Query_log_event::Query_log_event: added a check to ensure query length
      is respecting event buffer limits.
      
      Query_log_event::do_apply_event: extended a debug print, added a check
      to character set to determine if it is "parseable" or not, verified if
      database name is valid for system collation.
      
      Start_log_event_v3::do_apply_event: report an error on applying a
      non-supported binary log version.
      
      Load_log_event::copy_log_event: added a check to table_name length.
      
      User_var_log_event::User_var_log_event: added checks to avoid reading
      out of buffer limits.
      
      User_var_log_event::do_apply_event: reported an sanity check error
      properly and added individual sanity checks for variable types that
      expect fixed (or minimum) amount of bytes to be read.
      
      Rows_log_event::Rows_log_event: added checks to avoid reading out of
      buffer limits.
      
      @sql/log_event_old.cc
      
      Old_rows_log_event::Old_rows_log_event: added a sanity check to avoid
      reading out of buffer limits.
      
      @sql/sql_priv.h
      
      Added a sanity check to available_buffer() function.
      3fb2f8db
  8. 11 Jan, 2018 2 commits
    • Karthik Kamath's avatar
      BUG#27160888: MISSING FILE PRIVILEDGE CHECKS ON SOME · 2af9e8af
      Karthik Kamath authored
                    STATEMENTS
      
      ANALYSIS:
      =========
      A user not having FILE privilege is not allowed to create
      custom data/index directories for a table or for its
      partitions via CREATE TABLE but is allowed to do so via
      ALTER TABLE statement.
      
      ALTER TABLE ignores DATA DIRECTORY and INDEX DIRECTORY when
      given as table options. The issue occurs during the
      creation of partitions for a table via ALTER TABLE
      statement with the DATA DIRECTORY and/or INDEX DIRECTORY
      options. The issue exists because of the absence of FILE
      privilege check for the user.
      
      FIX:
      ====
      A FILE privilege check has been introduced for resolving
      the above scenario.
      2af9e8af
    • Bjorn Munch's avatar
      Bug #27021754 MYSQLTEST MAN PAGES WILL BE REMOVED, PACKAGING MUST BE PREPARED · 20e75a3e
      Bjorn Munch authored
       Followup: now that the man pages have actually been removed,
       we no longer need to take deliberate action to ignore them.
       Thus we can remove that part of the original change.
      
       RPM: drop the conditional removal
       DEB: remove from the exclude list
      20e75a3e
  9. 21 Dec, 2017 2 commits
  10. 05 Dec, 2017 1 commit
    • Karthik Kamath's avatar
      BUG#26881798: SERVER EXITS WHEN PRIMARY KEY IN MYSQL.PROC · 9e1035c6
      Karthik Kamath authored
                    IS DROPPED
      
      ANALYSIS:
      =========
      It is advised not to tamper with the system tables.
      When primary key is dropped from a system table, certain
      operations on the table which tries to access the table key
      information may lead to server exit.
      
      FIX:
      ====
      An appropriate error is now reported in such a case.
      9e1035c6
  11. 02 Dec, 2017 1 commit
    • Shishir Jaiswal's avatar
      Bug#26585560 - MYSQL DAEMON SHOULD CREATE ITS PID FILE AS · ecc5a078
      Shishir Jaiswal authored
                     ROOT
      
      DESCRIPTION
      ===========
      If the .pid file is created at a world-writable location,
      it can be compromised by replacing the server's pid with
      another running server's (or some other non-mysql process)
      PID causing abnormal behaviour.
      
      ANALYSIS
      ========
      In such a case, user should be warned that .pid file is
      being created at a world-writable location.
      
      FIX
      ===
      A new function is_file_or_dir_world_writable() is defined
      and it is called in create_pid_file() before .pid file
      creation. If the location is world-writable, a relevant
      warning is thrown.
      
      NOTE
      ====
      1. PID file is always created with permission bit 0664, so
      for outside world its read-only.
      2. Ignoring the case when permission is denied to get the
      dir stats since the .pid file creation would fail anyway in
      such a case.
      ecc5a078
  12. 27 Nov, 2017 3 commits
    • Karthik Kamath's avatar
      BUG#26502135: MYSQLD SEGFAULTS IN · 8bc828b9
      Karthik Kamath authored
                    MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPL
      
      ANALYSIS:
      =========
      Server sometimes exited when multiple threads tried to
      acquire and release metadata locks simultaneously (for
      example, necessary to access a table). The same problem
      could have occurred when new objects were registered/
      deregistered in Performance Schema.
      
      The problem was caused by a bug in LF_HASH - our lock free
      hash implementation which is used by metadata locking
      subsystem in 5.7 branch. In 5.5 and 5.6 we only use LF_HASH
      in Performance Schema Instrumentation implementation. So
      for these versions, the problem was limited to P_S.
      
      The problem was in my_lfind() function, which searches for
      the specific hash element by going through the elements
      list. During this search it loads information about element
      checked such as key pointer and hash value into local
      variables. Then it confirms that they are not corrupted by
      concurrent delete operation (which will set pointer to 0)
      by checking if element is still in the list. The latter
      check did not take into account that compiler (and
      processor) can reorder reads in such a way that load of key
      pointer will happen after it, making result of the check
      invalid.
      
      FIX:
      ====
      This patch fixes the problem by ensuring that no such
      reordering can take place. This is achieved by using
      my_atomic_loadptr() which contains compiler and processor
      memory barriers for the check mentioned above and other
      similar places.
      
      The default (for non-Windows systems) implementation of
      my_atomic*() relies on old __sync intrisics and implements
      my_atomic_loadptr() as read-modify operation. To avoid
      scalability/performance penalty associated with addition of
      my_atomic_loadptr()'s we change the my_atomic*() to use
      newer __atomic intrisics when available. This new default
      implementation doesn't have such a drawback.
      8bc828b9
    • Balasubramanian Kandasamy's avatar
      51e049cf
    • Balasubramanian Kandasamy's avatar
      946d9e4d
  13. 17 Nov, 2017 1 commit
    • Aditya A's avatar
      Bug #24296076 INNODB REPORTS WARNING WHILE INNODB_UNDO_LOG_TRUNCATE IS ENABLED · 63a540c8
      Aditya A authored
      PROBLEM
      -------
      
      This warning message is printed when trx_sys->rseg_history_len is greater than some
      arbitrary magic number (2000000). By seeing the reproducing scenario where we keep
      a read view open and do a lot of transactions on table which increases the hitsory
      length it is entirely possible that trx_sys->rseg_history_len can exceed 2000000.
      So this is not a bug due to corruption of history length.The warning message was
      just added to test some scenario and not removed.
      
      FIX
      ---
      
      1.Print this warning message only for debug versions.
      2.Modified the warning message with more detailed information.
      3.Don't crash even in debug versions.
      
      [#rb 17929 Reviewed by jimmy and satya]
      63a540c8
  14. 16 Nov, 2017 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #26881946: INCORRECT BEHAVIOR WITH "VALUES" · f06443ce
      Sreeharsha Ramanavarapu authored
      Issue:
      ------
      VALUES doesn't have a type() function and is considered a
      Item_field.
      
      Solution for 5.7:
      -----------------
      Add a new type() function for Item_values_insert.
      
      On 8.0 and trunk it was fixed by Mithun's Bug#19601973.
      
      Solution for 5.6:
      -----------------
      Additionally Bug#17458914 is backported.
      
      This will address the problem of using VALUES() in
      INSERT ... ON DUPLICATE KEY UPDATE. Create a field object
      only if it is in the UPDATE clause, else return a NULL
      item.
      
      This will also address the problems mentioned in
      Bug#14789787 and Bug#16756402.
      
      Solution for 5.5:
      -----------------
      As mentioned above Bug#17458914 is backported.
      
      Additionally Bug#14786324 is also backported.
      
      When VALUES() is detected outside its meaningful place,
      it should be treated as NULL and is thus replaced with a
      Field_null object, with the same name as the original
      field.
      
      Fields with type NULL are generally not handled well inside
      the server (e.g Innodb will not accept them and it is
      impossible to create them in regular tables). So create a
      new const NULL item instead.
      f06443ce
  15. 13 Nov, 2017 1 commit
  16. 09 Nov, 2017 2 commits
  17. 03 Nov, 2017 1 commit
  18. 26 Oct, 2017 1 commit
    • Arun Kuruvila's avatar
      Bug #26880757: MYISAM_USE_MMAP=1 ON WINDOWS FREQUENTLY DOES · bd1fe261
      Arun Kuruvila authored
                     NOT UPDATE FILE ON DISK
      
      Description:- When the server variable, "myisam_use_mmap" is
      enabled, MyISAM tables on windows are not updating the file
      on disk even when the server variable "flush" is set to 1.
      This is inturn making the table corrupted when encountering
      a power failure.
      
      Analysis:- When the server variable "myisam_use_mmap" is set,
      files of MyISAM tables will be memory mapped using the OS
      APIs mmap()/munmap()/msync() on Unix and CreateFileMapping()
      /UnmapViewOfFile()/FlushViewOfFile() on Windows. msync() and
      FlushViewOfFile() is responsible for flushing the changes
      made to the in-core copy of a file that was mapped into
      memory using mmap()/CreateFileMapping() back to the
      file system.  FLUSH is determined by the OS unless
      explicitly called using msync()/FlushViewOfFile().
      
      When the server variables "myisam_use_mmap" and "flush" are
      enabled, MyISAM is only flushing the files from file system
      cache to disc using "mysql_file_sync()" and not the memory
      mapped file from memory to FS cache using "my_msync()".
      ["my_msync()" inturn calls  msync() on Unix and
      FlushViewOfFile() on Windows.
      
      Fix:- As part of the fix, if server variable
      "myisam_use_mmap" is enabled along with  "flush",
      "my_msync()" is invoked to flush the data in memory to file
      system cache and followed by "mysql_file_sync()" which will
      flush the data from file system cache to disk.
      bd1fe261
  19. 23 Oct, 2017 1 commit
    • Karthik Kamath's avatar
      BUG#26529369: CREATE INDEX WITH LONG COMMENT CAUSE · a542209b
      Karthik Kamath authored
                    UNEXPECTED ERROR
      
      ANALYSIS:
      =========
      Creating many indexes with large amount of index
      information causes a server exit.
      
      FIX:
      ====
      A appropriate error is reported when the cumulative index
      information length exceeds the 2 byte range (i.e 65535).
      a542209b
  20. 19 Oct, 2017 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #26867652: INCORRECT BEHAVIOR WITH PREPARE STATEMENT · 84c32cdb
      Sreeharsha Ramanavarapu authored
                     AND PARAM IN ORDER BY
      
      Issue:
      ------
      This issue can occur when the ORDER BY list refers to a
      column that contains a parameter in the select list.
      
      Solution:
      ---------
      In JOIN::update_depend_map and get_sort_by_table, the
      ORDER BY list's used_tables isn't checked for parameters.
      This can result in incorrect behavior.
      
      This is a partial backport of Roy's
      84c32cdb
  21. 16 Oct, 2017 1 commit
  22. 09 Oct, 2017 1 commit
    • Tor Didriksen's avatar
      Backport patch for Bug#16877045 5.6-CLUSTER-7.3 WIN32 SQL_YACC.CC BUILD PROBLEM · aa6e69db
      Tor Didriksen authored
      Building with ninja shows the problem:
      cmake .. -G Ninja
      ninja
      ninja: error: dependency cycle: sql/GenServerSource -> sql/CMakeFiles/GenServerSource -> sql/sql_builtin.cc -> cmake_order_depends_target_sq
       sql/GenServerSource
      
      Bug#16877045 5.6-CLUSTER-7.3 WIN32 SQL_YACC.CC BUILD PROBLEM
       - Somewhat circular dependency caused by the configured files sql_builtin.cc  being included as
          part of the files to generate in sql/
       - Move sql_builtin.cc out of GEN_SOURCES variable.
       - Create new variable CONF_SOURCES to be used for configured files.
      aa6e69db
  23. 13 Sep, 2017 3 commits
    • mysql-builder@oracle.com's avatar
      No commit message · 1da916c3
      mysql-builder@oracle.com authored
      No commit message
      1da916c3
    • Anushree Prakash B's avatar
      Bug#26372491 - RCE THROUGH THE MISHANDLE OF BACKSLASH · 5ac61b2a
      Anushree Prakash B authored
      DESCRIPTION:
      ===========
      The bug is related to incorrect parsing of SQL queries
      when typed in on the CLI. The incorrect parsing can
      result in unexpected results.
      
      ANALYSIS:
      ========
      The scenarios mainly happens for identifier names
      with a typical combination of backslashes and backticks.
      The incorrect parsing can either result in executing
      additional queries or can result in query truncation.
      This can impact mysqldump as well.
      
      FIX:
      ===
      The fix makes sure that such identifier names are
      correctly parsed and a proper query is sent to the
      server for execution.
      
      (cherry picked from commit 31a372aa1c2b93dc75267d1f05a7f7fca6080dc0)
      5ac61b2a
    • mysql-builder@oracle.com's avatar
      No commit message · cf3fe5a2
      mysql-builder@oracle.com authored
      No commit message
      cf3fe5a2
  24. 08 Sep, 2017 2 commits
    • Tor Didriksen's avatar
      Bug#23072792 MYSQL_GROUP_SUFFIX DOES NOT WORK · d52edb75
      Tor Didriksen authored
      Reintroduce environment variable MYSQL_GROUP_SUFFIX to be used as
      --default-group-suffix value if not already set.
      
      The environment variable was accidentally renamed to DEFAULT_GROUP_SUFFIX_ENV
      in MySQL server 5.5.
      d52edb75
    • Anushree Prakash B's avatar
      Bug#26372491 - RCE THROUGH THE MISHANDLE OF BACKSLASH · 43632f4c
      Anushree Prakash B authored
      DESCRIPTION:
      ===========
      The bug is related to incorrect parsing of SQL queries
      when typed in on the CLI. The incorrect parsing can
      result in unexpected results.
      
      ANALYSIS:
      ========
      The scenarios mainly happens for identifier names
      with a typical combination of backslashes and backticks.
      The incorrect parsing can either result in executing
      additional queries or can result in query truncation.
      This can impact mysqldump as well.
      
      FIX:
      ===
      The fix makes sure that such identifier names are
      correctly parsed and a proper query is sent to the
      server for execution.
      43632f4c
  25. 07 Sep, 2017 1 commit
  26. 06 Sep, 2017 2 commits
  27. 31 Aug, 2017 1 commit
  28. 29 Aug, 2017 1 commit
  29. 24 Aug, 2017 1 commit
    • Ajo Robert's avatar
      Bug#26361149 MYSQL SERVER CRASHES AT: COL IN(IFNULL(CONST, · f7316aa0
      Ajo Robert authored
                             COL), NAME_CONST('NAME', NULL))
      
      Backport of Bug#19143243 fix.
      
      NAME_CONST item can return NULL_ITEM type in case of incorrect arguments.
      NULL_ITEM has special processing in Item_func_in function.
      In Item_func_in::fix_length_and_dec an array of possible comparators is
      created. Since NAME_CONST function has NULL_ITEM type, corresponding
      array element is empty. Then NAME_CONST is wrapped to ITEM_CACHE.
      ITEM_CACHE can not return proper type(NULL_ITEM) in Item_func_in::val_int(),
      so the NULL_ITEM is attempted compared with an empty comparator.
      The fix is to disable the caching of Item_name_const item.
      f7316aa0