Issue:
wsrep_notify_status() interpolated members[i].name() (the peer's
wsrep_node_name) and members[i].incoming() verbatim into a command
string that is then executed via 'sh -c' by wsp::process. A peer
joining the cluster with shell metacharacters in its wsrep_node_name
or wsrep_node_incoming_address caused arbitrary commands to run on
every cluster member that had wsrep_notify_cmd configured.
MDEV-39413 introduced safe() for the same threat class in the SST
scripts but did not cover the C++ wsrep_notify path.
Solution:
Validate each substituted field against a narrow whitelist before
interpolating. Node name allows alnum and -_. ; node address
additionally allows :[]/ for host:port and [ipv6] forms. On bad
input the notification is skipped with an error log instead of
forwarding the unsafe value to sh -c.
Issue:
wsrep_sst_rsync.sh interpolated WSREP_SST_OPT_REMOTE_USER and
WSREP_SST_OPT_REMOTE_PSWD verbatim. Because both values originate from
the joiner side of the SST request, a newline in either could splice
an extra directive into the donor-written stunnel.conf (silently
downgrading peer-cert verification) or an extra line into the rsync
magic file. MDEV-39413 had introduced safe() for the same threat class
in wsrep_sst_mariabackup but did not extend it to the rsync script.
Solution:
Routing the rsync interpolations through safe() closes the gap, and
extending safe() to also reject tab and newline ensures multi-line
values cannot survive into a config-file heredoc.
GROUP_CONCAT is limited by group_concat_max_len,
but also, as a string function it must respect max_allowed_packet.
Let's introduce THD::gconcat_max_len() helper to simplify checks.
Also:
* make max group_concat_max_len value the same as max max_allowed_packet
* use the same MY_MIN((ulonglong) ..., UINT_MAX32) in
Item_func_json_objectagg as in Item_func_group_concat
* use overflow-safe type for lengths in Item_func_quote
(MAX_MAX_ALLOWED_PACKET is 1G so uint cannot overflow yet, but it's
a fragile assumption)
max_subnet estimate was off by one.
* only allow address with a known family
(trips an assert in addr_matches_subnet())
* adjust max_subnet estimate accordinly
Joiner mariadbd exits when SST is aborted; the exit code varies by
platform (clean 0 on some systems, signalled 134 / 1 on others).
pkill exit code can also vary by platform (clean 0 on some systems,
signalled 1 others).
Add verification of wsrep_sst_donor, wsrep_sst_method and
wsrep_sst_receive_address so that they contain only
supported characters. But allow NULL or empty value.
Calling itself will cause extensive memory usage that can kill
the machine when it runs out of memory (happend to me).
Fixed by having mtr.out-of-source checking that it is not calling itself.
In addition added a check for cmake to expand symlinks to make the
check if we are running mtr 'out of source' safer.
Author: Sergei Golubchik <serg@mariadb.org> (CMakeList.txt changes)
Analysis:
When json is being parsed, the step decreases without a out-of-bound check
resulting in failure.
Fix:
Before decreasing the step, check if it will result into out of bound.
json_get_path_start() set p->last_step to p->steps - 1, creating a
pointer before the beginning of the steps[] array. This is undefined
behavior flagged by UBSAN as "index -1 out of bounds for type
json_path_step_t[32]".
Use NULL as the sentinel value instead, and check for NULL in
json_get_path_next() rather than comparing against p->steps.
Backport to 10.6 of commit 4f546897b8.
Additional test case from Rucha Deodhar
Signed-off-by: Varun Deep Saini <varun.23bcs10048@ms.sst.scaler.com>
Signed-off-by: Varun Deep Saini <deepsainivarun@gmail.com>
* use max_length=640
* also fix mroonga_highlight_html, mroonga_normalize, mroonga_snippet_html
* remove disable_cursor_protocol from all mroonga tests
* remove redundant checks for `len` in `get_param_length()`
* validate return value `length` in `get_param_length()`
* fix all `Item_param::set_param_XXX()` methods to never read past `len`
note that all `Item_param::set_param_XXX()` methods correctly handle
zero-length values.
Stop parsing index flags after reporting an invalid flag in
mrn_parse_grn_index_column_flags().
Otherwise, an invalid index comment such as flags "COMPRESS_ZSTD" can
make CREATE TABLE loop forever while emitting warnings. Add a regression
test for this case and check that the invalid flag is reported once and
the default index flags are used.
Problem:
========
Purge threads computing virtual columns could crash due to:
1. Stale TABLE* pointers when tables are flushed/rebuilt during purge
2. open_purge_table() called close_thread_tables() on failure, making
MDL tickets invalid before purge could release them
3. Purge coordinator opened TABLE* but workers accessed it with wrong
TABLE->in_use
4. No retry mechanism when open_purge_table() failed due to concurrent
FLUSH TABLES, BACKUP STAGE, or ALTER TABLE operations
Solution:
========
1. Removed close_thread_tables() from open_purge_table(). Purge
coordinator thread should close explicitly in close_and_reopen()
2. Added retry logic: when open_purge_table() returns NULL due to
table flush/rebuild, set must_wait() flag and retry in
close_and_reopen()
3. Update close_and_reopen() with purge_table parameter to
close the failed table. Pass it to trx_purge_close_tables()
for proper cleanup
4. Properly set and reset TABLE::in_use during purge operations:
- Set to coordinator_thd in row_purge_parse_undo_rec() when opening
- Reset in trx_purge_close_table() when closing
5. The auto_increment initialization now happens unconditionally for
purge threads , ensuring the auto_increment counter is always
properly initialized when purge opens tables with virtual columns
Problem:
========
A single InnoDB purge worker thread can process undo logs from different
tables within the same batch. But get_purge_table(), open_purge_table()
incorrectly assumes that a 1:1 relationship between a purge worker thread
and a table within a single batch. Based on this wrong assumtion,
InnoDB attempts to reuse TABLE objects cached in thd->open_tables for
virtual column computation.
1) Purge worker opens Table A and caches the TABLE pointer in thd->open_tables.
2) Same purge worker moves to Table B in the same batch, get_purge_table()
retrieves the cached pointer for Table A instead of opening Table B.
3) Because innobase::open() is ignored for Table B, the virtual column
template is never initialized.
4) virtual column computation for Table B aborts the server
Solution:
========
- Introduced purge_table class which has the following
purge_table: Stores either TABLE* (for tables with indexed virtual
columns) or MDL_ticket* (for tables without) in a single union
using LSB as a flag.
For tables with indexed virtual columns: opens TABLE*, accesses
MDL_ticket* via TABLE->mdl_ticket
For tables without indexed virtual columns: stores only MDL_ticket*.
trx_purge_attach_undo_recs(): Coordinator opens both dict_table_t*
and TABLE* with proper MDL protection. Workers access cached
table pointers from purge_node_t->tables without opening
their own handles
purge_sys.coordinator_thd: Distinguish coordinator from workers
in cleanup logic. Skip innobase_reset_background_thd() for
coordinator thread to prevent premature table closure during
batch processing. Workers still call cleanup to release their
thread-local resources
trx_purge_close_tables():
Rewrite for purge coordinator thread
1) Close all dict_table_t* objects first
2) Call close_thread_tables() once for all TABLE* objects
3) Release MDL tickets last, after tables are closed
Added table->lock_mutex protection when reading (or) writing
vc_templ->mysql_table and mysql_table_query_id. Clear cached
TABLE* pointers before closing tables to prevent stale pointer
access
Declared open_purge_table() and close_thread_tables() in trx0purge.cc
Declared reset_thd() in row0purge.cc and dict0stats_bg.cc.
Removed innobase_reset_background_thd()
Problem:
When a prepared statement uses `DEFAULT` with sequence, on its
second or subsequent execution, server tries to allocate TABLE_LIST
object (used for adding sequence table to `internal_tables` list) on
statement's memory root. This fails with an assert because statement's
memory root is marked read-only after the first execution.
CREATE SEQUENCE s;
CREATE TABLE t (a INT DEFAULT(NEXTVAL(s)));
PREPARE stmt FROM "UPDATE t SET a = ?";
EXECUTE stmt USING 3; -- first execution, marks mem_root read-only
EXECUTE stmt USING DEFAULT; -- tries to allocate on second execution
Fix:
Temporarily clear the read-only flag on the statement memory root to
allow the allocation. Also adds a debug hook to verify allocation
happens not more than once per prepared statement and per internal
table added to the list.
introduce safe() wrapper for parameters that can later be interpolated
into command line.
Use as
- var="foo$BAR"
+ var="foo$(safe BAR)"
A parameter is safe, if it contains no spaces, single quotes or backticks
