jeff@wubios.wustl.edu (Jeff Gabel) (12/11/90)
Configuration: Running elm 2.3 pl9 on Sun 3/260 under SunOS 4.1 Elm was configured without debugging enabled for this installation, so the error message we get is minimal. Bug: When using s)ave or C)opy for particular messages getting a fatal error (as follows): Bus error signal! Emergency exit taken! All temp files left intact! ---------- Essentially, if I send a message to mutiple recipients, with myself included as a recipient (i.e., I'm in both the `From:' and `To:' headers), and then attempt to save or copy it to the default folder for that message (in this case `jeff'), this error can occur. The relationship of the headers to this error is not totally clear, as I can simply mail myself a message and successfully save it. Also, things function normally when I Cc: myself, or just send to 1 or 2 other recipients besides myself. As a matter of fact, another user pointed out that attempting to save certain multiple recipient messages, in which they were not the sender, also generated this error. So, in fact, I'm guessing that the `To:' header probably doesn't come into play at all here; the correspondence of the `To:' header to this error is simply what I observed and I haven't had a chance to test any further. Thanks, Jeff | Internet % jeff@wubios.wustl.edu | Jeff Gabel, System/Network Slave | | UUCP % ...!uunet!wugate!wubios!jeff | Div. of Biostatistics, Box 8067 | |AT&T Mail % attmail!wubios!jeff | Washington U. School of Medicine | |Voice/FAX % +1 314 362 {3681/2693} | St. Louis, MO 63110 |
anderson@udder.macc.wisc.edu (Jess Anderson) (12/11/90)
In article <1990Dec10.204010.7183@wubios.wustl.edu> jeff@wubios.wustl.edu (Jeff Gabel) writes: >Configuration: Running elm 2.3 pl9 on Sun 3/260 under SunOS 4.1 >Elm was configured without debugging enabled for this installation, >so the error message we get is minimal. >Bug: When using s)ave or C)opy for particular messages getting a >fatal error (as follows): >Bus error signal! That's where I get Segment violation signal. >Emergency exit taken! All temp files left intact! >Essentially, if I send a message to mutiple recipients, with myself included >as a recipient (i.e., I'm in both the `From:' and `To:' headers), and then >attempt to save or copy it to the default folder for that message (in this >case `jeff'), this error can occur. The relationship of the headers to this >error is not totally clear, as I can simply mail myself a message and >successfully save it. Also, things function normally when I Cc: myself, or >just send to 1 or 2 other recipients besides myself. As a matter of fact, >another user pointed out that attempting to save certain multiple recipient >messages, in which they were not the sender, also generated this error. So, >in fact, I'm guessing that the `To:' header probably doesn't come into play at >all here; the correspondence of the `To:' header to this error is simply what >I observed and I haven't had a chance to test any further. In investigating this, I've determined that up to 5 addresses in the To: line seems to work all right. 6 or more causes the problem. I'm running PL9 on a DECstation 3100/Ultrix 3.1. Syd suggested recompiling with -DDEBUG turned on, then run elm -d10 to get more info, but I haven't had a chance to try that yet. -- Jess Anderson Madison Academic Computing Center University of Wisconsin Work: Rm. 3130, 1210 West Dayton St., Madison WI 53706, Ph. 608/262-5888 Home: 2838 Stevens St., 53705, 608/238-4833 Bitnet: anderson@wiscmacc Internet: anderson@macc.wisc.edu UUCP:{}!uwvax!macc.wisc.edu!anderson
gemini@geminix.in-berlin.de (Uwe Doering) (12/11/90)
anderson@udder.macc.wisc.edu (Jess Anderson) writes: >In article <1990Dec10.204010.7183@wubios.wustl.edu> >jeff@wubios.wustl.edu (Jeff Gabel) writes: > >>Configuration: Running elm 2.3 pl9 on Sun 3/260 under SunOS 4.1 >>Elm was configured without debugging enabled for this installation, >>so the error message we get is minimal. > >>Bug: When using s)ave or C)opy for particular messages getting a >>fatal error (as follows): > >>Bus error signal! > >That's where I get Segment violation signal. On a 386 system running ISC 2.0.2 UNIX I've got the same error. Not with the save function but rather when I wanted to reply to a mail. The problem was a `Received:' line that was longer than the 256 bytes of the Elm input buffer used to read in those lines. Now I wonder why there is no protection against buffer overflow at this point. And I don't understand why Elm uses static rather than dynamically allocated buffers to store header lines. I really don't feel comfortable knowing that other people (who create the header lines) can decide whether my mailer breaks or not. One simply can't rely on a miximum header line length. I circumvented the problem by doubling the buffer size, but this is only a hack and by no means a proper fix. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
syd@DSI.COM (Syd Weinstein) (12/12/90)
In article <2X6LL4K@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >anderson@udder.macc.wisc.edu (Jess Anderson) writes: >Now I wonder why there is no protection against buffer overflow at this >point. And I don't understand why Elm uses static rather than dynamically >allocated buffers to store header lines. I really don't feel comfortable >knowing that other people (who create the header lines) can decide whether >my mailer breaks or not. One simply can't rely on a miximum header line >length. I was going to let this pass, but I cannot, after I found the problem. Why is their no protection? But their was, the call that overflowed was a strncat, which did have a length check. Why didn't it work? Because a line got deleted that updated the length during my testing and re-assembly to check in the code prior to a patch. Why does Elm uses static (actually on the stack) buffers and not dynamic ones? Because Dave Taylor wrote it that way. Note, it wouldn't have broken if my boundry check didn't get messed up by the line deletion. Note, if you noticed that the problem was due to that buffer being overwritten, why didn't you notice that the length check wasn't getting the proper length? :-) Anyway, folks, its a one line patch to fix this one, I am debating whether to just release the one line patch as patch 10, or bundle more stuff in with it. Their is plenty in to in-box awaiting handling. For those interested here is the unofficial version of the diff (note the one line code change and the mucho doc change just to support it): Index: src/returnadd.c Prereq: 4.1.1.2 *** ../elm2.3/src/returnadd.c Wed Dec 5 23:42:09 1990 --- src/returnadd.c Tue Dec 11 15:36:10 1990 *************** *** 1,8 **** ! static char rcsid[] = "@(#)$Id: returnadd.c,v 4.1.1.2 90/12/05 22:33:58 syd Exp $"; /******************************************************************************* ! * The Elm Mail System - $Revision: 4.1.1.2 $ $State: Exp $ * * Copyright (c) 1986, 1987 Dave Taylor * Copyright (c) 1988, 1989, 1990 USENET Community Trust --- 1,8 ---- ! static char rcsid[] = "@(#)$Id: returnadd.c,v 4.1.1.3 90/12/11 15:35:56 syd Exp $"; /******************************************************************************* ! * The Elm Mail System - $Revision: 4.1.1.3 $ $State: Exp $ * * Copyright (c) 1986, 1987 Dave Taylor * Copyright (c) 1988, 1989, 1990 USENET Community Trust *************** *** 14,19 **** --- 14,23 ---- * ******************************************************************************* * $Log: returnadd.c,v $ + * Revision 4.1.1.3 90/12/11 15:35:56 syd + * Add back missing strlen line, fixes segv problem + * From: Syd + * * Revision 4.1.1.2 90/12/05 22:33:58 syd * Fix missing close brace due to indention error * From: Syd *************** *** 295,300 **** --- 299,305 ---- buf[len_buf] = '\0'; } strncat(buf, buf2, (SLEN-len_buf-1)); + len_buf = strlen(buf); ok = (int) (fgets(buf2, SLEN, mailfile) != NULL); if (ok) { len_buf2 = strlen(buf2); -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235