[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #14 from Frederick Eaton --- On Arch Linux, I think the only non-obvious packages needed to make the example compile are alsa-lib and libsndfile ... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #13 from Philippe Waroquiers --- (In reply to Julian Seward from comment #12) > Philippe, is there anything we can or should do here? The current hypothesis is that an ioctl used by alsa or a sound library is not properly handled by syswrap : the syscall wrapper does not see that the kernel will overwrite a memory zone. However, to confirm this (and fix the wrapper) implies to compile the test program (probably not very difficult, but still it does not compile out of the box: some include and/or dev libs are needed). After that, some knowledge of the sound ioctl-s are needed to see if/what is wrong. My knowledge of the sound sycalls are close to 0, so I cannot do this without a significant time (that I do not have); So, in summary, yes, there are things to do, but nobody has time to volunteer for the moment. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #12 from Julian Seward --- Philippe, is there anything we can or should do here? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Frederick Eaton changed: What|Removed |Added Attachment #100267|0 |1 is obsolete|| --- Comment #11 from Frederick Eaton --- Created attachment 100360 --> https://bugs.kde.org/attachment.cgi?id=100360&action=edit code and output file with (not-working) minimal test case -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #10 from Frederick Eaton --- Hi Philippe, Thanks for the suggestions. I'm afraid I don't have time to fix the full bug, and I think whoever updates syswrap-linux.c will want to have a working version of the bug to experiment with, so this is a good place for me to pass it off to the developers. FWIW I tried to create a minimal test case but it didn't work; valgrind caught the buffer overflow: ==19707== Invalid write of size 4 ==19707==at 0x510F183: sync_ptr1.isra.7 (pcm_hw.c:134) ==19707==by 0x51109CB: sync_ptr (pcm_hw.c:146) ==19707==by 0x51109CB: snd_pcm_hw_readi (pcm_hw.c:837) ==19707==by 0x40123B: main (minimal.cpp:83) I'm attaching the archive with minimal test case included. Good luck, Frederick -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #9 from Philippe Waroquiers --- > I hope it helps too! What do you want me to do now? Is there some > other tracing facility which I should run to help you identify the > problematic ioctl? Do you want me to make the example program more > minimal? Perhaps I could do the latter, otherwise I don't really have > much time - I just wanted to report this bug as a kind of housekeeping > task, so that upstream knows about the problem. We can maybe rename it > to something like "valgrind doesn't correctly track buffer overflows > from certain ALSA ioctls". Thank you, Yes, it would be nice to continue the investigation, as the ioctl hypothesis is not yet confirmed. So, the following would be useful: Discover which ioctl are done by snd_pcm_readi One way is to put a breakpoint on the line calling this function, and the next line. When the first breapoint is encountered, add a breakpoint on the ioctl syscall. Each time the ioctl breapoint triggers, write down the (symbolic) ioctl request (I guess the symbolic request will be seen in the source e.g. when doing GDB up) It is assumed that the ioctl done (or one of the ioctl done by this function) is using the buffer address as parameter. Would be nice to confirm that. The remaining mystery is : if really an ioctrl is 'badly' described in syswrap-linux.c, then that should create a lot of errors in memcheck (use of undefined memory). So, the ioctrl badly described hypothesis is still not (fully) understandable. The alternative to find which ioctl is done is to read the library source file. Thanks -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #8 from Frederick Eaton --- > Forcing the channel to 1 at that 'BUG' place has other consequences than just > allocating a 'too small' buffer. > As I understand, after this 'forcing to 1', we will also have > sfinfo.channels that will > be 1 instead of 2. No idea if that participates (or not) to the problem. I don't think it does, sfinfo is just used for the output file, if we give it a smaller number of channels then it will read less data from the buffer. > So, I will assume that this snd_pcm_readi is not doing a read syscall but is > rather > an ioctl, probably corresponding to this trace: > SYSCALL[14734,1](16) sys_ioctl ( 4, 0x80184151, 0xffefff170 ) --> [async] > ... > SYSCALL[14734,1](16) ... [async] --> Success(0x0) > > I am not sure how to translate this 0x80184151 into one of the 'symbolic' > ioctl > SND/PCM things handled in syswrap-linux.c. > I suspect that some SND/PCM ioctl are not properly described as > reading/writing the memory > pointed to by the ARG3 of the ioctl. Then of course, that might do a buffer > overrun > which is undetected by Valgrind, which then corrupts the end of the buffer > block > and the malloc data structure/memory/blocks following this (too small) > buffer. That sounds very likely to be the source of the problem, good detective work! > So, at this point, what we need to confirm is: > is snd_pcm_readi really doing an ioctl ? > if yes, which one ? (i.e. which 'symbolic' ioctl is it doing ?) > e.g. maybe it is case VKI_SOUND_PCM_READ_CHANNELS: > and if this is the case, then syswrap-linux.c describes that this ioctl > is writing the > size of an int, while it clearly reads more than an int, if the ioctl is > reading real data. > If now that is the bug, and syswrap-linux.c really should describe that it > reads a bunch > of bytes depending on previously set parameters, then I think that is a lot > of work to do, > as basically syswrap-linux.c will need to record the previous SND/PCM ioctl > to know what > is the expected size of such an ioctl ARG3. > > Now, maybe this ioctl is rather something like VKI_SNDRV_CTL_IOCTL_TLV_READ > but I do not see how that matches this buffer logic and the snd_pcm_readi, > which only > has a buffer argument. > > So, to understand where the undetected buffer overflow comes from, I guess > some > alsa/snd lib source code reading might be needed, to see how snd_pcm_readi > is implemented > in terms of ioctl. > We can then check if syswrap-linux.c properly describes what this ioctl is > accessing > in read and/or write mode. > > Hoping this helps I hope it helps too! What do you want me to do now? Is there some other tracing facility which I should run to help you identify the problematic ioctl? Do you want me to make the example program more minimal? Perhaps I could do the latter, otherwise I don't really have much time - I just wanted to report this bug as a kind of housekeeping task, so that upstream knows about the problem. We can maybe rename it to something like "valgrind doesn't correctly track buffer overflows from certain ALSA ioctls". Thank you, Frederick -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #7 from Philippe Waroquiers --- (In reply to Frederick Eaton from comment #6) > Hi Philippe, > > Thanks for responding. > > I'm using Arch Linux, it's weird that the default Arch package is not > to your liking. The assumption is that valgrind is (basically) build using configure/make/make install and that the resulting executables are not stripped (to ensure a.o. that the crash stack traces contains symbolic information). But everybody is free to compile valgrind as they want, this is free software :). And of course, then to get some help from Valgrind developers, very likely, we will prefer to have non stripped executables :). > Well I compiled from ABS adding (!strip debug) to > OPTIONS in /etc/makepkg.conf, the new version gives line numbers for > the backtrace. I attached the new output and also the output with the > verbose options you recommended. Thanks. This line/source nr allows to confirm that the valgrind malloc structure has been heavily corrupted. > In the original version I just called `snd_pcm_hw_params_set_channels` > and assumed the setting had been honored by ALSA. I requested 1 > channel, ALSA created 2 channels per device constraints, I allocated > space for 32768 1-channel "frames", ALSA return 32768 2-channel > frames. I got a buffer overflow. I hope this answers your question. I > imagine that my original submission was a bit confusing. Forcing the channel to 1 at that 'BUG' place has other consequences than just allocating a 'too small' buffer. As I understand, after this 'forcing to 1', we will also have sfinfo.channels that will be 1 instead of 2. No idea if that participates (or not) to the problem. But what you might do instead of changing channels to 1 is to just allocate a buffer with a size equal to frames * 2. Then we know that the only thing which is 'wrong' is the buffer size. That being said, assuming the too small buffer is the only cause of this corruption, the only 'modify' use of this buffer is likely in the source line: res = snd_pcm_readi(handle, buffer, frames); In the detailed trace, we see no matching read system call. So, I will assume that this snd_pcm_readi is not doing a read syscall but is rather an ioctl, probably corresponding to this trace: SYSCALL[14734,1](16) sys_ioctl ( 4, 0x80184151, 0xffefff170 ) --> [async] ... SYSCALL[14734,1](16) ... [async] --> Success(0x0) I am not sure how to translate this 0x80184151 into one of the 'symbolic' ioctl SND/PCM things handled in syswrap-linux.c. I suspect that some SND/PCM ioctl are not properly described as reading/writing the memory pointed to by the ARG3 of the ioctl. Then of course, that might do a buffer overrun which is undetected by Valgrind, which then corrupts the end of the buffer block and the malloc data structure/memory/blocks following this (too small) buffer. So, at this point, what we need to confirm is: is snd_pcm_readi really doing an ioctl ? if yes, which one ? (i.e. which 'symbolic' ioctl is it doing ?) e.g. maybe it is case VKI_SOUND_PCM_READ_CHANNELS: and if this is the case, then syswrap-linux.c describes that this ioctl is writing the size of an int, while it clearly reads more than an int, if the ioctl is reading real data. If now that is the bug, and syswrap-linux.c really should describe that it reads a bunch of bytes depending on previously set parameters, then I think that is a lot of work to do, as basically syswrap-linux.c will need to record the previous SND/PCM ioctl to know what is the expected size of such an ioctl ARG3. Now, maybe this ioctl is rather something like VKI_SNDRV_CTL_IOCTL_TLV_READ but I do not see how that matches this buffer logic and the snd_pcm_readi, which only has a buffer argument. So, to understand where the undetected buffer overflow comes from, I guess some alsa/snd lib source code reading might be needed, to see how snd_pcm_readi is implemented in terms of ioctl. We can then check if syswrap-linux.c properly describes what this ioctl is accessing in read and/or write mode. Hoping this helps -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Frederick Eaton changed: What|Removed |Added CC||frede...@ofb.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #6 from Frederick Eaton --- Hi Philippe, Thanks for responding. I'm using Arch Linux, it's weird that the default Arch package is not to your liking. Well I compiled from ABS adding (!strip debug) to OPTIONS in /etc/makepkg.conf, the new version gives line numbers for the backtrace. I attached the new output and also the output with the verbose options you recommended. > E.g. I do not see why the line after #ifndef BUG is needed: this seems to get > the nr of channels that were set just before ??? The program uses libsndfile and libasound (ALSA) as you can see. The ALSA library has elaborate mechanisms to resolve differences between settings that the user might request and restrictions that might be imposed by the hardware device. I should have used the function `snd_pcm_hw_params_set_channels_near` which takes a requested number of channels and returns the actual number assigned. http://alsa-lib.sourcearchive.com/documentation/1.0.8-3/group__PCM__HW__Params_g59aa9e1a02f4ce616fe92c605a833f8f.html#g59aa9e1a02f4ce616fe92c605a833f8f In the original version I just called `snd_pcm_hw_params_set_channels` and assumed the setting had been honored by ALSA. I requested 1 channel, ALSA created 2 channels per device constraints, I allocated space for 32768 1-channel "frames", ALSA return 32768 2-channel frames. I got a buffer overflow. I hope this answers your question. I imagine that my original submission was a bit confusing. The libraries are not too exotic, and although you need a soundcard with stereo inputs to reproduce the bug I imagine that's not such a rarity. However, let me know if the new files I submitted do not resolve the mystery for you, and then I can maybe work on a more minimal test case. Thanks, Frederick -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #5 from Frederick Eaton --- Created attachment 100309 --> https://bugs.kde.org/attachment.cgi?id=100309&action=edit verbose output -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Frederick Eaton changed: What|Removed |Added Attachment #100269|0 |1 is obsolete|| --- Comment #4 from Frederick Eaton --- Created attachment 100308 --> https://bugs.kde.org/attachment.cgi?id=100308&action=edit output file with line numbers in host stacktrace -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Philippe Waroquiers changed: What|Removed |Added CC||philippe.waroquiers@skynet. ||be --- Comment #3 from Philippe Waroquiers --- Thanks for the bug report. The program is however still quite big (> 400 SLOC), accesses a bunch of calls from sound related libraries, is using include files not installed by default (at least on my setup), and understanding what this program does is not trivial. E.g. I do not see why the line after #ifndef BUG is needed: this seems to get the nr of channels that were set just before ??? So, it would be nice if you could isolate the buffer overflow in the minimal program to cause valgrind crash, and largely preferrably without dependencies to sound libraries and similar. I understand that this might be far to be easy, so below are other ideas to help determine what is wrong in Valgrind. First, it is strange that in the output file, the host stack trace has no source/line nr. This valgrind seems to have been built/compiled an unusual way. Can you re-run with a valgrind compiled the 'classical way', so that the host stacktrace contains source/line nrs ? Also, it is normal that valgrind does not (always) detect buffer overflow. See e.g. manual for --redzone-size parameter. Try to re-run with the max allowed redzone size (4096) as this will detect the buffer overflow as long as the 'overflow' is less than 4Kb far from the end of the allocated buffer. (and of course, valgrind memcheck tool detects buffer overflow in malloc-ed buffers, but not buffers on the stack and global (you might try --tool=exp-sgcheck for that) or buffer overflows inside array inside struct. An undected buffer overflow normally however by itself should not lead to a SEGV inside valgrind code, so this is still puzzling. I am wondering if this is not the result of a side effect of hacking with the nr of channels (maybe due to a syscall with arguments not fully checked by Valgrind, leading to this SIGSEGV). It would be also nice to re-run with more trace e.g. -v -v -v -d -d -d --trace-syscalls=yes Thanks Philippe -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #2 from Frederick Eaton --- Created attachment 100269 --> https://bugs.kde.org/attachment.cgi?id=100269&action=edit output file only -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #1 from Frederick Eaton --- Created attachment 100267 --> https://bugs.kde.org/attachment.cgi?id=100267&action=edit code and output file You are welcome to critique my coding style. -- You are receiving this mail because: You are watching all bug changes.
