bugThe nmh Mail Handling System - Bugs: bug #11142, POP3 inc chokes on very long lines

 
 

bug #11142: POP3 inc chokes on very long lines

Submitted by:  Nick Barnes <nickbarnes>
Submitted on:  Fri 26 Nov 2004 03:04:13 PM UTC  
 
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalStatus: Wont Fix
Assigned to: NoneOpen/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 19 Dec 2012 12:22:12 AM UTC, comment #4:

I'm closing this, primarily based on the comment that it couldn't be replicated with 1.1rc3. Also, the code has changed so much in the last 8 years that the patch would no longer apply.

Also, I question whether it's necessary to support lines >1K.

David Levine <levine>
Project Member
Thu 17 Feb 2011 01:18:36 PM UTC, comment #3:

Migrating my mail home to a newer FreeBSD, I am offered nmh 1.2 by the ports collection. Is this bug fixed on nmh 1.2, or do I have to figure out how to port my patch across?
(nmh 1.2 seems to have been released about 4 years after I first reported this bug and provided a patch).

Nick Barnes <nickbarnes>
Sat 19 Nov 2005 04:55:35 PM UTC, comment #2:

Looking at the source, I don't think this bug has been fixed.

Peter Maydell <pm215>
Project Administrator
Fri 26 Nov 2004 03:11:58 PM UTC, comment #1:

Can't get a test message to fail with 1.1rc3, so maybe this is fixed already. Does anyone know?

Nick Barnes <nickbarnes>
Fri 26 Nov 2004 03:04:13 PM UTC, original submission:

inc from NMH 1.0.4_1 on FreeBSD chokes on very long lines (> 1K). Attached here is a patch which I developed which fixes this bug. I reported this to the nmh-bugs mailing list back in January 2002, and didn't really get any response. I've been maintaining it locally since then.

I don't know whether the bug is still present in 1.1rc3.

What's happening is that (when you have a line longer than 1K in the body of a message) the buffer filled from the POP3 connection is too large to be copied into another fixed-size
buffer along with a terminating \0. The problem is that the resulting buffer doesn't get a terminating \0, so if it is
sent to stdout or to a file with [f]printf("%s"), you get a read overflow and some amount of garbage output (and/or a crash if the buffer is just before an unmapped page in memory).

Nick Barnes <nickbarnes>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #2107:  nb-patch added by nickbarnes (15kB - application/octet-stream - patch for NMH 1.0.4)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by levine (Posted a comment)
  • -unavailable- added by nickbarnes (Posted a comment)
  • -unavailable- added by pm215 (Updated the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 19 Dec 2012 12:22:12 AM UTClevineStatusNone=>Wont Fix
      Open/ClosedOpen=>Closed
    Mon 29 Dec 2008 10:32:38 PM UTCpm215CategoryNone=>Bug
    Fri 26 Nov 2004 03:04:13 PM UTCnickbarnesAttached File-=>Added nb-patch, #1918

    Back to the top


    Powered by Savane 3.1-cleanup