This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001522] Array index out of bounds in tftp_server.c


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001522

--- Comment #10 from Grant Edwards <grant.b.edwards@gmail.com> 2012-08-09 17:27:25 BST ---
(In reply to comment #9)

> one other thing with the code is this: a valid socket handle is a
> number >= 0.
>
> if (server->s[i]) {
>             FD_SET(server->s[i],&readfds);
>
> what if socket returns 0, because we have not stdio, i.e. inside a
> daemon?

You're right. There isn't any stdin/stdout/stderr or any concept of a
daemon in eCos, and 0 is a perfectly valid value for a socket file
descriptor.  FWIW: in Unix, daemons do have stdin/stdout/stderr
(descriptors 0,1,2) but they're usually connected to /dev/null.

> should'nt it be like this:
> if (server->s[i]>=0) {
>             FD_SET(server->s[i],&readfds);
> 
> and
> 
>  if (server->s[i]>=0) {
>                   close (server->s[i]);
>                   server->s[i] = -1;
>                 }

Yes, you're correct.

Using 0 as a "none" sentinal value for a socket/file descriptor is a
bug. It's not an unusual mistake to make, and for Unix programs it's
never detected because stdin is (almost) always fd 0, but I tripped
over the same thing in some other eCos code I wrote years ago.

Want to submit a patch?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]