[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime

[Frederick Eaton via KDE Bugzilla]

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

[Frederick Eaton via KDE Bugzilla]

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=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

[Frederick Eaton via KDE Bugzilla]

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

[Frederick Eaton via KDE Bugzilla]

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

[Frederick Eaton via KDE Bugzilla]

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

[Frederick Eaton via KDE Bugzilla]

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

[Frederick Eaton via KDE Bugzilla]

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=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

[Frederick Eaton via KDE Bugzilla]

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=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

[Frederick Eaton via KDE Bugzilla]

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=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

[Frederick Eaton via KDE Bugzilla]

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=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.

[valgrind] [Bug 366035] New: valgrind misses buffer overflow, segfaults in malloc in localtime

[Frederick Eaton via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366035

Bug ID: 366035
   Summary: valgrind misses buffer overflow, segfaults in malloc
in localtime
   Product: valgrind
   Version: 3.11.0
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: frede...@ofb.net

I get the following error when I use Valgrind to debug my buggy program:

--433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--433-- si_code=128;  Faulting address: 0x0;  sp: 0x802ba9e30

valgrind: the 'impossible' happened:
   Killed by fatal signal

Turns out it was a simple buffer overflow but Valgrind didn't catch it.

Since the code is fairly small, I thought it might be useful to submit.

I made a tar file with the valgrind output, my code, and the command to run it.

You need to run the code on a machine with a sound card.

Thanks.


Reproducible: Always




I hope I get to upload an attachment after clicking "Submit Bug Report"!

-- 
You are receiving this mail because:
You are watching all bug changes.