Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.1, 5.5.30, 5.1.67, 5.2.14, 5.3.12
-
None
-
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.
Attachments
Activity
Percona Server is affected as well, https://bugs.launchpad.net/percona-server/+bug/1173282
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.
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.
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.
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)