MariaDB 10.11.17 SIGSEGV in mysql_multi_update() when executing UPDATE ... INNER JOIN ... SET ... against InnoDB tables on a Galera/WSREP node.

Frequency

Reproducible in production when the affected application job runs.

Observed crashes:

Tue 2026-05-19 00:00:06 CEST SIGSEGV
Wed 2026-05-20 00:00:07 CEST SIGSEGV
Thu 2026-05-21 00:00:09 CEST SIGSEGV
Fri 2026-05-22 00:00:09 CEST SIGSEGV
Sat 2026-05-23 00:00:11 CEST SIGSEGV
Sun 2026-05-24 00:00:11 CEST SIGSEGV
Mon 2026-05-25 00:02:04 CEST SIGSEGV, core present, 143.2M

Actual crashing query

The core dump shows the crashing session was executing this application query pattern:

UPDATE bag_num p
INNER JOIN bag_num_data d
ON p.pendingCurrentID = d.id
AND p.pendingCurrentAppearance = d.appearance
SET
p.currentID = p.pendingCurrentID,
p.currentAppearance = p.pendingCurrentAppearance,
p.pendingCurrentID = NULL,
p.pendingCurrentAppearance = NULL
WHERE p.pendingCurrentID IS NOT NULL
AND d.beginGeldigheid <= CURDATE();

This comes from application code that builds the same query generically for different parent/data table pairs:

private async activateEntity(parentTable: string, dataTable: string): Promise<number> {
const result = await this.dataSource.query(`
UPDATE ${parentTable} p
INNER JOIN ${dataTable} d
ON p.pendingCurrentID = d.id
AND p.pendingCurrentAppearance = d.appearance
SET
p.currentID = p.pendingCurrentID,
p.currentAppearance = p.pendingCurrentAppearance,
p.pendingCurrentID = NULL,
p.pendingCurrentAppearance = NULL
WHERE p.pendingCurrentID IS NOT NULL
AND d.beginGeldigheid <= CURDATE()
`)

return result.affectedRows || 0
}

Stack trace evidence

The crashing thread is Thread 2, LWP 276018.

Relevant stack trace:

Thread 2 (Thread 0xd07e6d48640 (LWP 276018)):
#0 0x000055c92b1f6706 in mysql_multi_update (
thd=thd@entry=0xd075801dfe8,
table_list=0xd075800cd48,
fields=fields@entry=0xd0758022de0,
values=values@entry=0xd0758023248,
conds=0xd075800fd58,
options=0,
handle_duplicates=DUP_ERROR,
ignore=false,
unit=0xd07580222e8,
select_lex=0xd0758022b28,
result=0xd07e6d46eb0
) at /usr/src/debug/MariaDB-/src_0/sql/sql_update.cc:2045

table = 0x0
tablel = 0xd0758011130
transactional = true
non_trans = false
total_list =

#1 0x000055c92b11c577 in mysql_execute_command(...)
at /usr/src/debug/MariaDB-/src_0/sql/sql_parse.cc:4584

#2 0x000055c92b11e0f7 in mysql_parse(...)
at /usr/src/debug/MariaDB-/src_0/sql/sql_parse.cc:8221

#3 0x000055c92b11e951 in wsrep_mysql_parse(...)
at /usr/src/debug/MariaDB-/src_0/sql/sql_parse.cc:8031

#4 0x000055c92b12188f in dispatch_command(...)
command=COM_QUERY

The core shows table = 0x0 in mysql_multi_update() at sql/sql_update.cc:2045, suggesting a null table pointer dereference in the multi-table update path.

The query buffer in the same thread contains the affected SQL:

UPDATE bag_num p
INNER JOIN bag_num_data d
ON p.pendingCurrentID = d.id
AND p.pendingCurrentAppearance = d.appearance
SET
p.currentID = p.pendingCurrentID,
...
beginGeldigheid <= CURDATE()

This appears in mysql_parse(), wsrep_mysql_parse(), and dispatch_command() for the crashing session.

Main thread after crash

The main thread is later seen during WSREP shutdown:

#3 wsrep_close_client_connections(...)
#4 wsrep_stop_replication_common(thd=0x0)
#5 wsrep_shutdown()
#6 mysqld_main(...)

This appears to be shutdown aftermath, not the original crash location. The crashing thread is the mysql_multi_update() thread above.

Kernel log signature

The kernel consistently reports:

mariadbd[...] segfault at 8 ip ... error 4 in mariadbd[...]
Code: ... <48> 8b 52 08 ...

The fault address 8 is consistent with a null pointer plus offset dereference.