[MDEV-4422] SHOW PROCESSLIST reference to THD::db not protected against simultaneous updates Created: 2013-04-23  Updated: 2013-06-14  Resolved: 2013-06-13

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.1, 5.5.30, 5.1.67, 5.2.14, 5.3.12
Fix Version/s: 10.0.4, 5.5.32

Type: Bug Priority: Major
Reporter: Kristian Nielsen Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None


 Description   

SHOW PROCESSLIST accesses the current db (THD::db) of each thread without
any protection against simultaneous update (by THD::set_db()).

        if ((thd_info->db=tmp->db))             // Safe test
 
          thd_info->db=thd->strdup(thd_info->db);

This can result in reading free()d memory, in theory returning sensitive data
or even crashing (if free() decided to munmap() the memory).

A possible solution is to protect THD::set_db() calls, as well as reading of
THD::db from SHOW PROCESSLIST, by the LOCK_thd_data mutex.

 Comments   
Comment by Kristian Nielsen [ 2013-04-23 ]

Valgrind report for reference, though this appears to be a general problem rather than a specific Valgrind issue:

rpl.rpl_stop_slave 'mix,xtradb' w5 [ fail ] Found warnings/errors in server log file!
Test ended at 2013-04-22 22:05:12
line
==9897== Thread 20:
==9897== Invalid read of size 1
==9897== at 0x4C2826B: memcpy (mc_replace_strmem.c:878)
==9897== by 0xBAF9E8: strmake_root (my_alloc.c:424)
==9897== by 0x63C74E: mysqld_list_processes(THD*, char const*, bool) (sql_class.h:771)
==9897== by 0x5C8574: mysql_execute_command(THD*) (sql_parse.cc:3149)
==9897== by 0x5CC844: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5759)
==9897== by 0x5CDDC9: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1068)
==9897== by 0x5CE4BD: do_command(THD*) (sql_parse.cc:794)
==9897== by 0x6A4E23: do_handle_one_connection(THD*) (sql_connect.cc:1266)
==9897== by 0x6A4F23: handle_one_connection (sql_connect.cc:1181)
==9897== by 0x8F0027: pfs_spawn_thread (pfs.cc:1015)
==9897== by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so)
==9897== by 0x62F713C: clone (in /lib64/libc-2.9.so)
==9897== Address 0x1a06a973 is 3 bytes inside a block of size 5 free'd
==9897== at 0x4C257D8: free (vg_replace_malloc.c:446)
==9897== by 0xBB96BB: my_free (my_malloc.c:115)
==9897== by 0x838C86: Query_log_event::do_apply_event(Relay_log_info const*, char const*, unsigned int) (sql_class.h:2846)
==9897== by 0x53904C: apply_event_and_update_pos(Log_event*, THD*, Relay_log_info*) (log_event.h:1230)
==9897== by 0x5446DD: exec_relay_log_event(THD*, Relay_log_info*) (slave.cc:2766)
==9897== by 0x545BD9: handle_slave_sql (slave.cc:3627)
==9897== by 0x8F0027: pfs_spawn_thread (pfs.cc:1015)
==9897== by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so)
==9897== by 0x62F713C: clone (in /lib64/libc-2.9.so)

Comment by Laurynas Biveinis [ 2013-04-26 ]

Percona Server is affected as well, https://bugs.launchpad.net/percona-server/+bug/1173282

Comment by Kristian Nielsen [ 2013-05-07 ]

Suggestion from Serg (on maria-developers@):

I'd say, let's use a fixed buffer in 5.1-5.5.
In 10.0 a better way would be to use Sergey Petrunia's
APC subsystem for that.

Comment by Peter (Stig) Edwards [ 2013-06-13 ]

Thank you.
I was wondering if 5.3.13 will get the fix? 5.3.12 is listed as affected. Is the policy to only fix versions prior to the current stable release if the bug is critical?
I realize you have to draw the line somewhere for fixes such as this, I couldn't find a description of a "Life Cycle" policy or guidance on what to expect for patches to versions older than the current stable release. I suspect I will need to upgrade to 5.5.32 or 10.0.4 (or above) to pick this up, just looking for confirmation on this, thanks again.

Comment by Sergei Golubchik [ 2013-06-13 ]

In a sense. You'd really prefer to upgrade to 5.5. While 5.3 is still maintained, minor bug fixes might not get into it. And releases are rare, you'd need to wait few months for a fixed version, for 5.5 is usually about one month.

Comment by Peter (Stig) Edwards [ 2013-06-14 ]

OK, thanks.

Generated at Thu Feb 08 06:56:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.