Opened 9 months ago

Closed 4 months ago

#1428 closed defect (fixed)

Embedded test triggers invalid read in Valgrind and asan

Reported by: sjamaan Owned by:
Priority: major Milestone: 4.14.0
Component: core libraries Version: 4.12.0
Keywords: embedding, callbacks, read error Cc:
Estimated difficulty: medium

Description

$ cd tests
$ csc -e embedded3.c embedded4.scm
$ valgrind ./embedded4
==12520== Memcheck, a memory error detector
==12520== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==12520== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==12520== Command: ./embedded4
==12520== 
==12520== Invalid read of size 8
==12520==    at 0x4C30140: memcpy@GLIBC_2.2.5 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12520==    by 0x57D4530: C_callback (runtime.c:2020)
==12520==    by 0x57D4723: C_callback_wrapper (runtime.c:2067)
==12520==    by 0x50CCEEB: CHICKEN_read (eval.c:2064)
==12520==    by 0x10A82B: main (embedded3.c:24)
==12520==  Address 0x68bc490 is 0 bytes after a block of size 2,048 alloc'd
==12520==    at 0x4C2BBAF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12520==    by 0x57D005F: CHICKEN_initialize (runtime.c:682)
==12520==    by 0x57D27CA: CHICKEN_run (runtime.c:1477)
==12520==    by 0x10A815: main (embedded3.c:22)
==12520== 
==12520== Invalid read of size 8
==12520==    at 0x4C3014E: memcpy@GLIBC_2.2.5 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12520==    by 0x57D4530: C_callback (runtime.c:2020)
==12520==    by 0x57D4723: C_callback_wrapper (runtime.c:2067)
==12520==    by 0x50CCEEB: CHICKEN_read (eval.c:2064)
==12520==    by 0x10A82B: main (embedded3.c:24)
==12520==  Address 0x68bc498 is 8 bytes after a block of size 2,048 alloc'd
==12520==    at 0x4C2BBAF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12520==    by 0x57D005F: CHICKEN_initialize (runtime.c:682)
==12520==    by 0x57D27CA: CHICKEN_run (runtime.c:1477)
==12520==    by 0x10A815: main (embedded3.c:22)
==12520== 
data: 0x00000000067f7348
embedded4: runtime.c:2068: C_callback_wrapper: Assertion `C_temporary_stack == C_temporary_stack_bottom' failed.
==12520== 
==12520== Process terminating with default action of signal 6 (SIGABRT)
==12520==    at 0x6447FCF: raise (raise.c:51)
==12520==    by 0x64493F9: abort (abort.c:89)
==12520==    by 0x6440E36: __assert_fail_base (assert.c:92)
==12520==    by 0x6440EE1: __assert_fail (assert.c:101)
==12520==    by 0x57D475F: C_callback_wrapper (runtime.c:2068)
==12520==    by 0x50CCCE4: CHICKEN_get_error_message (eval.c:2046)
==12520==    by 0x10A8D9: main (embedded3.c:34)
==12520== 
==12520== HEAP SUMMARY:
==12520==     in use at exit: 1,157,016 bytes in 1,820 blocks
==12520==   total heap usage: 1,835 allocs, 15 frees, 1,165,293 bytes allocated
==12520== 
==12520== LEAK SUMMARY:
==12520==    definitely lost: 0 bytes in 0 blocks
==12520==    indirectly lost: 0 bytes in 0 blocks
==12520==      possibly lost: 0 bytes in 0 blocks
==12520==    still reachable: 1,157,016 bytes in 1,820 blocks
==12520==         suppressed: 0 bytes in 0 blocks
==12520== Rerun with --leak-check=full to see details of leaked memory
==12520== 
==12520== For counts of detected and suppressed errors, rerun with: -v
==12520== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
zsh: abort      valgrind ./embedded4

I don't quite understand why this is happening yet, but it looks like the value of C_temporary_stack is below C_temporary_stack_bottom. It gets put below the value in C_save() in the callback, I think.

We also need to determine whether this is a security issue. Current thoughts are that it might be, if the size of the invalid read is determined by the size of the argvector, which might be determined by the user (though the callback will raise an exception if that's not a valid argument count).

Change History (2)

comment:1 Changed 4 months ago by sjamaan

  • Milestone changed from 4.13.0 to 4.14.0

We must have overlooked this ticket somehow

comment:2 Changed 4 months ago by sjamaan

  • Resolution set to fixed
  • Status changed from new to closed

Actually, we fixed it (see 226bfc25d56716b666fdc58b907ed4adf3b1620d), just forgot to close the ticket

Note: See TracTickets for help on using tickets.