On Sun, Sep 11, 2016 at 02:47:22PM -0500, Shaun Tancheff wrote:
> On Thu, Sep 8, 2016 at 2:19 PM, Tobias Stoeckmann <tobias@xxxxxxxxxxxxxx> wrote:
> > The text-utility ul can run into a buffer overflow on very long lines.
> > See this proof of concept how to reproduce the issue:
> >
> > $ dd if=/dev/zero bs=1M count=10 | tr '\000' '\041' > poc.txt
> > $ echo -ne '\xe\x5f\x8\x5f\x61\x2\xf\x5f\x8\x5f' | dd of=poc.txt conv=notrunc
> > $ ul -i poc.txt > /dev/null # output would take ages
> > Segmentation fault
> > $ _
> >
> > The problem manifests by using alloca with "maxcol", which can be as
> > large as INT_MAX, based on the input line.
> >
> > A very long line (> 8 MB) with modes must be supplied to ul, as seen in
> > my proof of concept byte sequence above.
> >
> > It is rather easy to fix this issue: allocate space on the heap instead.
> > maxcol could overflow here, but in that case no system will have enough
> > space to handle the request, properly ending ul through an err() call.
> >
> >
> > Signed-off-by: Tobias Stoeckmann <tobias@xxxxxxxxxxxxxx>
> > ---
> > text-utils/ul.c | 14 ++++----------
> > 1 file changed, 4 insertions(+), 10 deletions(-)
Applied, thanks.
>
> Just a nit .. may as well change 'i' from an int to a long here as well.
> That should cover the theoretical overflow for 64 bit machines.
This is generic problem of the 'ul' code, on many many places it uses 'int'
rather than 'size_t'. It would be better to fix it completely rather
than just one 'i' ;-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
