Read past end of buffer in xt_scan_branch_single() and similar functions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MariaDB |
New
|
Undecided
|
Unassigned | ||
PBXT |
In Progress
|
Undecided
|
Vladimir Kolesnikov |
Bug Description
I found this from a Valgrind warning:
==3619== Invalid read of size 4
==3619== at 0x9FF73F: xt_get_
==3619== by 0x9F4E90: xt_scan_
==3619== by 0x9FEE6B: xt_idx_
==3619== by 0xA1924B: xt_tab_
==3619== by 0x9EECD9: ha_pbxt:
==3619== by 0x7C4CC1: handler:
==3619== by 0x7E3087: copy_data_
==3619== by 0x7F05E2: mysql_alter_
==3619== by 0x68BE71: mysql_execute_
==3619== by 0x692F7F: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:6034)
==3619== by 0x693D91: dispatch_
==3619== by 0x69528F: do_command(THD*) (sql_parse.cc:886)
==3619== by 0x68066C: handle_
==3619== by 0x50463F6: start_thread (pthread_
==3619== by 0x6026B4C: clone (in /usr/lib/
==3619== Address 0xcf98030 is 0 bytes after a block of size 33,701,888 alloc'd
==3619== at 0x4C22FAB: malloc (vg_replace_
==3619== by 0x9FF9A2: xt_malloc(
==3619== by 0xA439F2: xt_ind_
==3619== by 0x9EBDBC: pbxt_call_
==3619== by 0x9EC109: pbxt_init(void*) (ha_pbxt.cc:1194)
==3619== by 0x7C8E01: ha_initialize_
==3619== by 0x88ADD6: plugin_
==3619== by 0x88E979: plugin_init(int*, char**, int) (sql_plugin.
==3619== by 0x67A21C: init_server_
==3619== by 0x67ACF5: main (mysqld.cc:4541)
This is from test case pbxt.multi_update (which takes ~1h to run under
Valgrind :-/).
I think this is a real bug, although possibly minor. Not knowing the code in
detail, I need help in determining the proper fix.
xt_scan_
memory. There is a while () loop, which exits with i pointing at the position
being searched for.
Note that (at least from a quick look at the code), if the value being
searched for is bigger than all values in the buffer, then the loop will exit
with i pointing past the last element.
After the loop, the code does this:
bitem = base + i * full_item_size;
From the Valgrind trace, it seems to me the problem is that in this case i
points past the last element as described above, so the
xt_get_
This should probably be fixed (in theory this could cause the process to
segfault if memory allocation is really unfortunate and these 8 bytes happen
to be unmapped). Maybe just something like
if (result.sr_found)
in case the values read are only used in the "found" case?
Hope you can sort out the rest from this explanation.
Changed in maria: | |
assignee: | nobody → Vladimir Kolesnikov (vkolesnikov) |
Changed in pbxt: | |
assignee: | nobody → Vladimir Kolesnikov (vkolesnikov) |
Changed in maria: | |
assignee: | Vladimir Kolesnikov (vkolesnikov) → nobody |
Changed in pbxt: | |
status: | New → In Progress |
Here is a similar Valgrind error for xt_scan_ branch_ fix(), which can be
obtained by running test case pbxt.type_enum (much easier, takes only about 1
minute under Valgrind):
==7276== Invalid read of size 4 res_record_ ref(unsigned char*, XTIdxResult*) (index_xt.h:454) branch_ fix(XTTable* , XTIndex*, XTIdxBranch*, XTIdxKeyValue*, XTIdxResult*) (index_xt.cc:622) insert( XTOpenTable* , XTIndex*, unsigned, unsigned, unsigned char*, unsigned char*, int) (index_xt.cc:1877) new_record( XTOpenTable* , unsigned char*) (table_xt.cc:4392) :write_ row(unsigned char*) (ha_pbxt.cc:2645) :ha_write_ row(unsigned char*) (handler.cc:4642) cc:1632) command( THD*) (sql_parse.cc:3244) command( enum_server_ command, THD*, char*, unsigned) (sql_parse.cc:1247) one_connection (sql_connect. cc:1132) create. c:297) debug/libc- 2.7.so) malloc. c:207) XTThread* , unsigned long) (memory_xt.cc:101) init(XTThread* , unsigned long) (cache_xt.cc:632) init(XTThread* ) (ha_pbxt.cc:974) handlerton( st_plugin_ int*) (handler.cc:429) initialize( st_plugin_ int*) (sql_plugin. cc:1033) cc:1258) components( ) (mysqld.cc:4069)
==7276== at 0x9FF73F: xt_get_
==7276== by 0x9F878E: xt_scan_
==7276== by 0x9FEE6B: xt_idx_
==7276== by 0xA1924B: xt_tab_
==7276== by 0x9EECD9: ha_pbxt:
==7276== by 0x7C4CC1: handler:
==7276== by 0x728939: write_record(THD*, st_table*, st_copy_info*) (sql_insert.
==7276== by 0x72D504: mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) (sql_insert.cc:860)
==7276== by 0x68CDF5: mysql_execute_
==7276== by 0x692F7F: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:6034)
==7276== by 0x693D91: dispatch_
==7276== by 0x69528F: do_command(THD*) (sql_parse.cc:886)
==7276== by 0x68066C: handle_
==7276== by 0x50463F6: start_thread (pthread_
==7276== by 0x6026B4C: clone (in /usr/lib/
==7276== Address 0xcf9802e is 33,701,886 bytes inside a block of size 33,701,888 alloc'd
==7276== at 0x4C22FAB: malloc (vg_replace_
==7276== by 0x9FF9A2: xt_malloc(
==7276== by 0xA439F2: xt_ind_
==7276== by 0x9EBDBC: pbxt_call_
==7276== by 0x9EC109: pbxt_init(void*) (ha_pbxt.cc:1194)
==7276== by 0x7C8E01: ha_initialize_
==7276== by 0x88ADD6: plugin_
==7276== by 0x88E979: plugin_init(int*, char**, int) (sql_plugin.
==7276== by 0x67A21C: init_server_
==7276== by 0x67ACF5: main (mysqld.cc:4541)
Seems like exactly the same issue as xt_scan_ branch_ single( ). Probably all the
xt_scan_branch_* functions needs to be checked for this issue.