PXC-4614 Merge PS 5.7.44-52 (POST EOL 4) #2052
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RM-1419 PS-5.7.44-51 (post-EOL 3)
https://perconadev.atlassian.net/browse/PS-9352 Bug#35507223 mysql/mysql-server@3a27636ac1b In MySQL 8.0 there are cases in which ~NO_ACCESS bitmask is passed as "access" argument to get_privilege_desc() function. In the past, before Bug#35507223 was fixed, this could have caused crash due to out of bounds array access. Since we can't totally exclude that the same thing is possible in 5.7 branch we have decided to fix potential problem there as well, by adding simple check for out of bounds array access.
PS-9352 Avoid out of bounds access due to ulong bitmask
…ry code execution. https://perconadev.atlassian.net/browse/PS-9434 WL#16482 mysql/mysql-server@2cc37b271ef Introduced a --[skip-]system-command command line/config file option for the mysql binary. Type: boolean Default: ON, can be turned off with --skip-system-command When --skip-system-command is specified and a system command or the abbreviated \! is specified, an error will be printed and the command won't be executed. Test case added. Change-Id: I46e8f3cc8e8a6aa37f8374c04a87177604cd124e
https://perconadev.atlassian.net/browse/PS-9434 Bug#36816986 mysql/mysql-server@ff0b5d82553 mysql/mysql-server@2c422606c58 mysql/mysql-server@f034c387d8e Problem: mysqldump does not sanitize the SQL statements which might contain some special characters like new line feed etc. Because of this, a user can inject arbitrary shell command(s) in to the dump file created by mysqldump. And if that file is executed on a host machine, the shell command will get executed on that host machine. Solution: The fix is to make sure that the rows which are being fetched from dump_tablespaces are sanitized properly. This fix is just sanitizing the rows coming in from mysql_fetch_row while dumping tablespaces. Change-Id: Ide74636ba60fd3cb6c936149f76b3c4ead70ecc9
https://perconadev.atlassian.net/browse/PS-9434 Bug#36593265 mysql/mysql-server@c6997b13cfa When converting a MySQL String to an std::string, use {ptr(), length()} rather than strlen(). Change-Id: Ie59965ecccf9846cf5c18b90b572328263c1cefa
…005" error https://perconadev.atlassian.net/browse/PS-9434 Bug#36492114 mysql/mysql-server@0f8002cf6ae Description: ------------ A stored procedure often causes MySQL to stop with a "mysqld got exception 0xc0000005" error. This occurs while applying join order hints. The stored procedure has been executed continuously several thousand times, with the same error occurring approximately once every 2,000 executions. After removing the QB_NAME hint from the procedure, the issue no longer occurred. Analysis: ------------ Based on the analysis, the issue occurs only with stored procedures that include a `SELECT` query with `QB_NAME` and `JOIN_*` hints. The failure happens when hint's `query_block_name` and `Table_ref`'s `query_block_name` are compared in `set_join_hint_deps()`. In `db_load_routine()`, the stored procedure definition string (`String defstr`) is created and passed to the parser as an input buffer. The parser creates a `PT_qb_level_hint` object with a `Hint_param_table` (which holds the `table_name` and `query_block_name`) and then pushes it to the `join_order_hints` list. Since `defstr` is created as a local variable, when `db_load_routine()` goes out of scope, `defstr` is destroyed. However, `Hint_param_table::opt_query_block` is still pointing to the `defstr` location. Later, while executing `apply_join_order_hints()`, `compare_table_name()` tries to access `hint_table->opt_query_block`, leading to a heap-use-after-free error. It appears that the issue lies with the lexical scanner for hint comments. The token pointer for `query_block_name` is not allocated as a string outside of the input buffer(`defstr`). The hint parser uses `Hint_scanner::scan_query_block_name()` to scan the query block name from hint comments. In `scan_query_block_name()`, if the token doesn't contain backquotes or double quotes, it simply returns the current token pointer, pointing to the input buffer. This heap-use-after-free error is easily visible with Asan, hard to reproduce with normal build. Fix: ---- Ensure the token pointer of `query_block_name` to point to a string allocated outside of the lex input buffer. This approach is similar to how the query block name is handled when using backquotes and double quotes. Change-Id: Ib9b117529c27955add4ac722ce2b2c1b56dad462
https://perconadev.atlassian.net/browse/PS-9434 Bug#36871927 mysql/mysql-server@2dd5e2ededb The results are truncated because the metadata for function DATABASE() indicates a string with maximum length 34 characters. This happens because the length is taken from the constant value MAX_FIELD_NAME instead of the correct NAME_CHAR_LEN (which gives the maximum length of a typical identifier in the data dictionary). The fix is to replace the wrong constant value. In addition, the constant MAX_FIELD_NAME is removed since it is basically unused. The only other use (in check_if_keyname_exists() to synthesize a key name) is replaced with a value that makes the index name use up to 64 single-byte characters, including underscore and a generated two-digit sequence number. Change-Id: I94b6327d0b8e867c9776afe3e68dd0e0ab83a939
https://perconadev.atlassian.net/browse/PS-9434 Bug#36210202 mysql/mysql-server@81a7f6fab54 mysql/mysql-server@97e8e62c9cc Problem: The method of comparing doc ids in FTS is incorrect - to determine which id is greater, first 64-bit unsigned subtraction is performed on them, and then the result is cast to 32-bit signed integer. This leads to incorrect results when the subtraction result is not in range of 32-bit signed values. This leads to further incorrect behavior in FTS including ranking score calculation. Fix: Subtraction "hack" replaced with simple comparison operators. Patch based on contribution from Alibaba's Shaohua Wang. Thank you! Change-Id: I5149d4de5de3c7e6732c1905fe54437ef7eb22e7
https://perconadev.atlassian.net/browse/PS-9434 Bug#36684463 mysql/mysql-server@4ea181e95f0 Do not return pointer to stack data, copy the result to 'tmp_value' which is in some mem_root (on the heap). Change-Id: I909e1faa6d175074f2ff925cce2d046e5f8e3a16 (cherry picked from commit 6d49e032d2fda8ebf5bb5033b3335a8b44831d0d)
https://perconadev.atlassian.net/browse/PS-9434 Bug#36600203 mysql/mysql-server@de82d8ade0a Problem: There is a return statement after the momory is allocated and before the memory is freed. The return may be reached before the memory is needed. Fix: Move the memory allocation after the return statement.
…in same transaction https://perconadev.atlassian.net/browse/PS-9434 Bug#36559642 mysql/mysql-server@5484c73368a mysql/mysql-server@a8b3732507e mysql/mysql-server@c25f8c03be8 Cause: When all FULLTEXT indexes are dropped from a table, but another one is added in the same transaction using INPLACE algorithm, the logic for dropping the last FULLTEXT index performs cleanup on the assumption that the in-memeory and on-disk FTS infrastructure is not needed any more. Because of the way the INPLACE algorithm works, creation of said infrastructure for the index being added and related checks will have already been done at this point - the index is already added but not yet published (the in-memory fts_t structure is not updated) and thus not detected. This leaves the infrastructure in an inconsistent state, leading to incorrect behavior. Fix: When dropping a FULLTEXT index, do not perform the cleanup if another FULLTEXT index is to be added in the same transaction. Test case added. Change-Id: Iceed9f4c755d2cd44d2cf7b301fc0f3a18a521cc
PS-9442 Backport bug fixes from MySQL 8.0.40
https://perconadev.atlassian.net/browse/PS-9442 Raised MYSQL_VERSION_EXTRA to 52 in MYSQL_VERSION file. Raised PERCONA_INNODB_VERSION to 52 in univ.i file.
PS-9645 Backport bug fixes from MySQL 8.0.40
https://perconadev.atlassian.net/browse/PXC-4614 Merge tag 'Percona-Server-5.7.44-52' into PXC-4614 Fourth post EOL Percona Server release 5.7.44-52 Conflicts: MYSQL_VERSION
https://perconadev.atlassian.net/browse/PXC-4614 * Resolved conflicts in MYSQL_VERSION.
https://perconadev.atlassian.net/browse/PXC-4614 The gcc, g++ compiler version is 4.8.0 on CentOS 7 which causes compilation failures on old code in PXC 5.7. So, supressing the warning.
https://perconadev.atlassian.net/browse/PXC-4614 Also, increases the column size for error log in MTR because when a test is run with valgrind, it generates much bigger error logs compared to the same test running in regular environment. This causes a lot of warnings in MTR.
https://perconadev.atlassian.net/browse/PXC-4614 ==367838== Conditional jump or move depends on uninitialised value(s) ==367838== at 0x4852055: bcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==367838== by 0x17BDFED: wsrep_init_position() (wsrep_mysqld.cc:930) ==367838== by 0x17BE1C2: wsrep_init() (wsrep_mysqld.cc:967) ==367838== by 0x17BF1F5: wsrep_init_startup(bool) (wsrep_mysqld.cc:1290) ==367838== by 0x1792908: mysqld_main(int, char**) (mysqld.cc:6328) ==367838== by 0xF2341C: main (main.cc:32) ==367838== ==367838== Conditional jump or move depends on uninitialised value(s) ==367838== at 0x51B929C: _itoa_word (_itoa.c:178) ==367838== by 0x51D4ABD: __vfprintf_internal (vfprintf-internal.c:1516) ==367838== by 0x51E7499: __vsnprintf_internal (vsnprintf.c:114) ==367838== by 0x51BF855: snprintf (snprintf.c:31) ==367838== by 0x21326B1: wsrep_uuid_print (wsrep_uuid.c:75) ==367838== by 0x17BE054: wsrep_init_position() (wsrep_mysqld.cc:938) ==367838== by 0x17BE1C2: wsrep_init() (wsrep_mysqld.cc:967) ==367838== by 0x17BF1F5: wsrep_init_startup(bool) (wsrep_mysqld.cc:1290) ==367838== by 0x1792908: mysqld_main(int, char**) (mysqld.cc:6328) ==367838== by 0xF2341C: main (main.cc:32) ==367838==
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://perconadev.atlassian.net/browse/PXC-4614
Merge tag 'Percona-Server-5.7.44-52' into PXC-4614
Fourth post EOL Percona Server release 5.7.44-52
Conflicts:
MYSQL_VERSION