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: unassigned at bugs dot ecos dot sourceware dot org
- Date: Thu, 9 Aug 2012 18:33:50 +0100
- Subject: [Bug 1001522] Array index out of bounds in tftp_server.c
- Auto-submitted: auto-generated
- References: <bug-1001522-777@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 #12 from Grant Edwards <grant.b.edwards@gmail.com> 2012-08-09 18:33:46 BST ---
(In reply to comment #11)
> (In reply to comment #10)
> > 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.
Ah, it looks we've already hashed through the "0 is a valid socket"
thing in this thread. Sorry about repeating myself.
> > Want to submit a patch?
> Well, ok. But is no one working on the idea with the blocking socket reads?
I'm afraid I'm not. I don't use tftp and don't even have any
filesystem which it could access. I only stumbled across the original
bug because I was getting sick of wasting so much time sorting through
all the compiler warnings trying figure out which ones mattered and
which ones didn't.
More than once I fell victim to a bug in code I wrote, and about which
gcc had warned me, because there were hundreds and hunders of other
mostly benign warnings generated by existing code.
> If I am to fix that issue I would prefer a completely simple solution.
>
> 1. let only one thread enter the select.
> 2. never close the sockets, because that throws any additionally
> received packets away.
> 3. post the semaphore before the switch(ntohs(hdr->th_opcode))
> 4. wait for the semaphore again, and go directly to the select.
I think the existing code is rather badly and fundamentally broken.
If I were going to re-write it I'd probably throw out the whole
multi-thread prallel operation business and do a single-threaded, one
transfer at a time version that's as simple to understand and as
obviously correct as possible.
I don't know what the use case is for multiple parallel transfers. If
I _were_ to use tftp it would be for firmware updates which I'd force
to be a single transfer at a time anyway.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.