This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001522] Array index out of bounds in tftp_server.c
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Thu, 9 Aug 2012 17:27:28 +0100
- Subject: [Bug 1001522] Array index out of bounds in tftp_server.c
- Auto-submitted: auto-generated
- References: <bug-1001522-13@http.bugs.ecos.sourceware.org/>
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.