From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3769 invoked by alias); 1 Jul 2012 02:37:39 -0000 Received: (qmail 3757 invoked by uid 22791); 1 Jul 2012 02:37:38 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD 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; Sun, 01 Jul 2012 02:37:25 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id F18302F78009; Sun, 1 Jul 2012 03:37:23 +0100 (BST) 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 MoPslRPGnwuc; Sun, 1 Jul 2012 03:37:22 +0100 (BST) Received: from lert.jifvik.org (jifvik.dyndns.org [85.158.45.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jlarmour@ecoscentric.com) by mail.ecoscentric.com (Postfix) with ESMTP id 73F542F78008; Sun, 1 Jul 2012 03:37:22 +0100 (BST) Message-ID: <4FEFB7E1.307@eCosCentric.com> Date: Sun, 01 Jul 2012 02:37:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Graves, Daniel (GE Healthcare)" CC: ecos-discuss@ecos.sourceware.org References: <6F6D3EC964AAC24D9C45644424DE2D810C2F6486@CINMLVEM19.e2k.ad.ge.com> In-Reply-To: <6F6D3EC964AAC24D9C45644424DE2D810C2F6486@CINMLVEM19.e2k.ad.ge.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Serial Driver imrpovement X-SW-Source: 2012-07/txt/msg00001.txt.bz2 On 22/06/12 17:10, Graves, Daniel (GE Healthcare) wrote: > I found that the following code in Serial.c will cause a buffer overflow > if there is garbage data on the wire before a thread has started reading > from the serial port: > > ------------------------------------------------ > static rcv_req_reply_t > serial_data_rcv_req(serial_channel *chan, int avail, > int* space_avail, unsigned char** space) > { [snip] > // Check for space > gap = cbuf->nb; > if (gap == cbuf->len) > return CYG_RCV_FULL; > > ---------------------- > > The line gap == cbuf->len will not always evaluate to true if garbage data > is received. This will cause the put variable to shoot way past len. I don't yet follow the situation you are concerned about. This generic layer doesn't know about garbage data. Garbage data is just data, and whether before or after a thread has started reading from the serial port, the underlying hardware serial driver needs to call serial_data_rcv_req() when data is received and act accordingly based on the return code. Based on what you're saying, you are implying that cbuf->nb > cbuf->len ? If so, then something has gone wrong... I imagine that the hardware driver is not respecting space_avail on return from serial_data_rcv_req(). Are you using an eCos serial driver or something you wrote yourself? Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss