https://bugs.kde.org/show_bug.cgi?id=366035
--- Comment #8 from Frederick Eaton <frede...@ofb.net> --- > 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.
