On 24.03.2020 19:37, Kamil Rytarowski wrote: > On 24.03.2020 15:41, Robert Elz wrote: >> Date: Tue, 24 Mar 2020 13:27:45 +0100 >> From: Kamil Rytarowski <n...@gmx.com> >> Message-ID: <5ec1195a-f1c8-cd46-6a14-ea29da109...@gmx.com> >> >> | I patched it myself only when I reproduced the problems myself. >> >> I have no doubt that there's a bug that needs fixing - it is the fix >> proposed that is wrong. My guess is that most probably it is simply >> doing nothing useful (no harm, no good either) but I need to confirm >> that. If it is, the correct fix is simply to delete the line (both >> times it was changed). If not, there's a more serious problem elsewhere >> that needs fixing elsewhere (after which the line can be deleted!) >> >> | OK. I will do it and please fix it in a better way. >> >> Working on it now. >> > > Thanks. > >> I haven't seen the revert yet, when I do I will commit the fix (or a fix, >> this one is somewhat debatble what is correct, though what is there now >> is obviously wrong ... but just like the one in question, while wrong, it >> is, in practice, harmless, at least in any normal use of librump). >> >> The fix for this issue needs to wait until the real problem the offending >> line is there to deal with (if any, which I suspect is not the case) is >> found. >> > > ASan detects not a hypothetical, but factual momory corruption. > > I'm attaching a report from ASan. > > ================================================================= > ==11092==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x60200000101e at pc 0x7f7ff6a10419 bp 0x7f7fe942fcb0 sp 0x7f7fe942fca8 > WRITE of size 1 at 0x60200000101e thread T30 > #0 0x7f7ff6a10418 in handlereq > /usr/src/lib/librumpuser/rumpuser_sp.c:984:18 > #1 0x7f7ff6a10418 in spserver > /usr/src/lib/librumpuser/rumpuser_sp.c:1280:7 > #2 0x7f7ff660cf36 in pthread__create_tramp > /usr/src/lib/libpthread/pthread.c:587:11 > > 0x60200000101e is located 0 bytes to the right of 14-byte region > [0x602000001010,0x60200000101e) > allocated by thread T30 here: > #0 0x311793 in malloc (/usr/bin/rump_server+0x111793) > #1 0x7f7ff6a0e5bb in readframe > /usr/src/lib/librumpuser/sp_common.c:505:18 > #2 0x7f7ff6a0e5bb in spserver > /usr/src/lib/librumpuser/rumpuser_sp.c:1268:13 > #3 0x7f7ff660cf36 in pthread__create_tramp > /usr/src/lib/libpthread/pthread.c:587:11 > > Thread T30 created by T0 here: > #0 0x2e054d in pthread_create (/usr/bin/rump_server+0xe054d) > > SUMMARY: AddressSanitizer: heap-buffer-overflow > /usr/src/lib/librumpuser/rumpuser_sp.c:984:18 in handlereq > Shadow bytes around the buggy address: > 0x4c04000001b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c04000001c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c04000001d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c04000001e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c04000001f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > =>0x4c0400000200: fa fa 00[06]fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c0400000210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c0400000220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c0400000230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c0400000240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x4c0400000250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > Shadow gap: cc > ==11092==ABORTING > > Getting now more debug info is too time consuming (build times are > excessive in my setup). >
Ping? This still breaks.
