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 #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.


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