[levent-tracker] [ levent-Bugs-2841177 ] ioctl: Strange behaviour leads to infinite loop

[SourceForge.net <no...@so...>]

Bugs item #2841177, was opened at 2009-08-20 21:45
Message generated for change (Tracker Item Submitted) made by the_zett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=461322&aid=2841177&group_id=50884

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libevent-core
Group: v1.4 (other)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: the_zett (the_zett)
Assigned to: Nobody/Anonymous (nobody)
Summary: ioctl: Strange behaviour leads to infinite loop

Initial Comment:
Hi,

I have caught a strange behaviour of libevent-1.4.12-stable on my linux vds.
# > uname -a
# Linux localhost 2.6.18-028stab062.3-ent #1 SMP Thu Mar 26 15:12:05 MSK 2009 i686 i686 i386 GNU/Linux

I have used 'evbuffer_read()' with a regular file descriptor. The file had size 4347 bytes and there were two calls of 'evbuffer_read()'. The first call returned 4096 bytes, but second one never completed. 

I did some traces and found that 'ioctl(fd, FIONREAD, &n)' sets 'n' to a negative value! I didn't find any description of such behaviour but it is real.


<++> gdb.log.1
evbuffer_read (buf=0x94dce00, fd=9, howmuch=251) at buffer.c:354
354		size_t oldoff = buf->off;
...
355		int n = EVBUFFER_MAX_READ;  /* 4096 */
...
362		if (ioctl(fd, FIONREAD, &n) == -1 || n == 0) {
...
(gdb) p n
$4 = -4096
<-->

<++> strace.log
ioctl(6, FIONREAD, [-4096])             = 0
<-->

So then it would enter an infinite loop at
<++> gdb.log.2
264	int
265	evbuffer_expand(struct evbuffer *buf, size_t datlen)
266	{
...
285			while (length < need)
286				length <<= 1;
<-->
('length' is going to be 0 through overflow)

I think it is needed to find the source of such 'ioctl()' behavior. But I don't know where to start at. And at least 'evbuffer_expand()' should be protected against integer overflow.

---
Thanks,
Alexander Pronchenkov


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=461322&aid=2841177&group_id=50884