From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6060 invoked by alias); 9 Mar 2012 16:12:08 -0000 Received: (qmail 5958 invoked by uid 22791); 9 Mar 2012 16:12:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Mar 2012 16:11:50 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E97902F78001 for ; Fri, 9 Mar 2012 16:11:49 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpDBnXTmW5RA; Fri, 9 Mar 2012 16:11:45 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001522] Array index out of bounds in tftp_server.c X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: TCP/IP X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: grant.b.edwards@gmail.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 09 Mar 2012 16:12:00 -0000 Message-Id: <20120309161144.78DAD2F78003@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2012/txt/msg00524.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001522 --- Comment #4 from Grant Edwards 2012-03-09 16:11:42 GMT --- (In reply to comment #3) > Why not move the "close loop" to below the switch statement that calls > tftpd_send_error()? Because then the sockets don't get closed until after the file operation completes and you loose the possibility of doing multiple file operations in parallel? If that's the case, then the ckeck for invalid opcode and error response needs to happen before the "close loop", but the actual handling of the read/write opcode needs to happen after the "close loop"? I must admit, I don't really understand why the sockets are being closed at all. Can't multiple threads read from a single socket? -- 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.