[MDEV-20312] InnoDB encryption accesses memory outside of allocated block part 2 Created: 2019-08-10  Updated: 2020-09-03  Resolved: 2020-09-03

Status: Closed
Project: MariaDB Server
Component/s: Encryption, Storage Engine - InnoDB
Affects Version/s: 10.5
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michael Widenius Assignee: Marko Mäkelä
Resolution: Cannot Reproduce Votes: 0
Labels: need_feedback
Environment:

./BUILD/compile-pentium64-valgrind-max

Issue Links:
PartOf
is part of MDEV-20310 valgrind bugs found in 10.5 Open
Relates
relates to MDEV-20309 InnoDB encryption accesses memory out... Closed

 Description    

mtr --valgrind encryption.innodb-compressed-blob encryption.innochecksum
 
 
 
==16528== Invalid read of size 2
 
==16528==    at 0x4C356A7: memmove (vg_replace_strmem.c:1271)
 
==16528==    by 0x15763CB: wolfSSL_EVP_CipherUpdate (evp.c:361)
 
==16528==    by 0x1437729: MyCTX::update(unsigned char const*, unsigned int, unsigned char*, unsigned int*) (my_crypt.cc:85)
 
==16528==    by 0x143796F: MyCTX_nopad::update(unsigned char const*, unsigned int, unsigned char*, unsigned int*) (my_crypt.cc:143)
 
==16528==    by 0x14372F1: my_aes_crypt_update (my_crypt.cc:310)
 
==16528==    by 0x160A4E3: ctx_update(void*, unsigned char const*, unsigned int, unsigned char*, unsigned int*) (file_key_management_plugin.cc:145)
 
==16528==    by 0xADF5FA: encryption_crypt (service_encryption.h:119)
 
==16528==    by 0xADFF2F: do_crypt(unsigned char const*, unsigned int, unsigned char*, unsigned int*, st_encryption_scheme*, unsigned int, unsigned int, unsigned int, unsigned long long, int) (encryption.cc:223)
 
==16528==    by 0xADFFD1: encryption_scheme_decrypt (encryption.cc:244)
 
==16528==    by 0x12CDC0A: fil_space_decrypt_full_crc32(unsigned long, fil_space_crypt_t*, unsigned char*, unsigned char*, dberr_t*) (fil0crypt.cc:842)
 
==16528==    by 0x12CE1AB: fil_space_decrypt(unsigned long, fil_space_crypt_t*, unsigned char*, unsigned long, unsigned long, unsigned char*, dberr_t*) (fil0crypt.cc:976)
 
==16528==    by 0x12CE311: fil_space_decrypt(fil_space_t const*, unsigned char*, unsigned char*, bool*) (fil0crypt.cc:1011)
 
==16528==    by 0x1225662: buf_page_decrypt_after_read(buf_page_t*, fil_space_t*) (buf0buf.cc:555)
 
==16528==    by 0x1236C18: buf_page_io_complete(buf_page_t*, bool, bool) (buf0buf.cc:6019)
 
==16528==    by 0x126133D: buf_read_page_low(dberr_t*, bool, unsigned long, unsigned long, page_id_t, unsigned long, bool, bool) (buf0rea.cc:203)
 
==16528==    by 0x1261AE7: buf_read_page(page_id_t, unsigned long) (buf0rea.cc:411)
 
==16528==  Address 0x10120000 is 0 bytes after a block of size 16,384 alloc'd
 
==16528==    at 0x4C30833: memalign (vg_replace_malloc.c:908)
 
==16528==    by 0x4C30936: posix_memalign (vg_replace_malloc.c:1072)
 
==16528==    by 0x123B9B6: aligned_malloc(unsigned long, unsigned long) (buf0buf.cc:130)
 
==16528==    by 0x12250C1: buf_tmp_reserve_crypt_buf(buf_tmp_buffer_t*) (buf0buf.cc:441)
 
==16528==    by 0x1225626: buf_page_decrypt_after_read(buf_page_t*, fil_space_t*) (buf0buf.cc:550)
 
==16528==    by 0x1236C18: buf_page_io_complete(buf_page_t*, bool, bool) (buf0buf.cc:6019)
 
==16528==    by 0x126133D: buf_read_page_low(dberr_t*, bool, unsigned long, unsigned long, page_id_t, unsigned long, bool, bool) (buf0rea.cc:203)
 
==16528==    by 0x1261AE7: buf_read_page(page_id_t, unsigned long) (buf0rea.cc:411)
 
==16528==    by 0x1231BA8: buf_page_get_gen(page_id_t, unsigned long, unsigned long, buf_block_t*, unsigned long, char const*, unsigned int, mtr_t*, dberr_t*) (buf0buf.cc:4380)
 
==16528==    by 0x1268263: dict_hdr_get(mtr_t*) (dict0boot.cc:49)
 
==16528==    by 0x126893A: dict_boot() (dict0boot.cc:276)
 
==16528==    by 0x116D1EA: srv_start(bool) (srv0start.cc:1881)
 
==16528==    by 0xF83B6C: innodb_init(void*) (ha_innodb.cc:4127)
 
==16528==    by 0xBA2FC4: ha_initialize_handlerton(st_plugin_int*) (handler.cc:550)
 
==16528==    by 0x8A3030: plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) (sql_plugin.cc:1437)
 
==16528==    by 0x8A3C2C: plugin_init(int*, char**, int) (sql_plugin.cc:1719)



 Comments   
Comment by Marko Mäkelä [ 2019-08-19 ]

MSAN (as described in MDEV-20377 and MDEV-20309) did not find anything wrong, but MSAN is only tracking uninitialized values, not addressable bytes.

I cannot repeat this with Valgrind, because I am hitting an internal error. This was cmake -DWITH_SSL=bundled:

10.5 da53fb6d7de906fd8bd73d5f244bac4d77b687aa

 
2019-08-19 14:50:46 0 [Note] Server socket created on IP: '127.0.0.1'.
 
VEX temporary storage exhausted.
 
Pool = TEMP,  start 0x596435a8 curr 0x59afbcf8 end 0x59b080e7 (size 5000000)
 
 
 
vex: the `impossible' happened:
 
   VEX temporary storage exhausted.
 
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
 
vex storage: T total 2758230384 bytes allocated
 
vex storage: P total 512 bytes allocated
 
 
 
valgrind: the 'impossible' happened:
 
   LibVEX called failure_exit().
 
 
 
host stacktrace:
 
==18867==    at 0x58048D1C: show_sched_status_wrk (m_libcassert.c:388)
 
==18867==    by 0x58048E37: report_and_quit (m_libcassert.c:459)
 
==18867==    by 0x5804908B: panic (m_libcassert.c:535)
 
==18867==    by 0x5804908B: vgPlain_core_panic_at (m_libcassert.c:540)
 
==18867==    by 0x580490AA: vgPlain_core_panic (m_libcassert.c:545)
 
==18867==    by 0x5805FB04: failure_exit (m_translate.c:751)
 
==18867==    by 0x581413FA: vpanic (main_util.c:255)
 
==18867==    by 0x5814147D: private_LibVEX_alloc_OOM (main_util.c:183)
 
==18867==    by 0x581E5F1C: LibVEX_Alloc_inline (main_util.h:178)
 
==18867==    by 0x581E5F1C: addHInstr_SLOW (host_generic_regs.c:334)
 
==18867==    by 0x581CFADF: emit_instr (host_generic_reg_alloc3.c:303)
 
==18867==    by 0x581CFADF: doRegisterAllocation_v3 (host_generic_reg_alloc3.c:1322)
 
==18867==    by 0x5813EA08: libvex_BackEnd (main_main.c:1083)
 
==18867==    by 0x5813EA08: LibVEX_Translate (main_main.c:1186)
 
==18867==    by 0x580625C6: vgPlain_translate (m_translate.c:1813)
 
==18867==    by 0x580A432B: handle_chain_me (scheduler.c:1167)
 
==18867==    by 0x580A6DAF: vgPlain_scheduler (scheduler.c:1516)
 
==18867==    by 0x580F6560: thread_wrapper (syswrap-linux.c:103)
 
==18867==    by 0x580F6560: run_a_thread_NORETURN (syswrap-linux.c:156)

With ASAN, I see no failure when using cmake -DWITH_SSL=system, and also not when using cmake -DWITH_SSL=bundled.

I am afraid that this will have to be investigated after MDEV-20309 has been analyzed and fixed.

Comment by Marko Mäkelä [ 2020-05-29 ]

Is this still repeatable for you, Monty? I recently ran MemorySanitizer on 10.5 (as noted in MDEV-20377), and did not see any issues in InnoDB.

Comment by Michael Widenius [ 2020-08-03 ]

Will try to repeat when back home later this week

Comment by Michael Widenius [ 2020-09-03 ]

I could originally repeat this on my machine, but not anymore.

Generated at Thu Feb 08 08:58:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.