8276 - we corrupt memory if senders separated by ';'

Assignee

Description

•

26 years ago

This report came from Jean-Francois:

The short summary is that when you send a message and separate multiple senders
using a ';' (which is illegal, it should be a comma, but you could enter it by
accident) we corrupt memory and crash unpleasantly.

I don't believe this is a common thing. So this isn't a critical crasher that
needs fixed for M7. But any crash is bad and we should figure why we can't
handle the ';'....

When I send a message to two recipient separated by a ";" instance of a ",", I
get the memory overwritten. I don't know if the
origin of the problem is in mime or it's a smtp matter:

here is the trace of the problem. First I get an Assertion message cause by
msg_quote_phrase_or_addr(char*, int, int)+00618:

User break at 16247064 dprintf(const char*, ...)+00098
 Assertion: "" (new_length == (out - orig_out)) at file nsMsgHeaderParser.cpp,
line 943

 Return addresses on the stack
  Stack Addr  Frame Addr   ISA   Caller
  [I have removed the begining]
   063CA5DC    063CA5D4    PPC   1790EDE8
nsMsgComposeAndSend::CreateAndSendMessage(nsIMsgCom
pFields*, int, int, nsMsgDeliverMode, const char*, const char*, unsigned int,
const nsMsgAtta
chmentData*, const nsMsgAttachedFile*, void*, unsigned int (*)(unsigned int,
void*, nsFileSpe
c*), vo+000AC
   063CA5A4                68K   063CAA12
   063CA54C    063CA544    PPC   1790C588
nsMsgComposeAndSend::Init(nsMsgCompFields*, nsFileS
pec*, int, int, nsMsgDeliverMode, const char*, const char*, unsigned int, const
nsMsgAttachme
ntData*, const nsMsgAttachedFile*, nsMsgSendPart*, void*)+002C8
   063CA544                68K   063CA5D2
   063CA4FC                PPC   1660DA80 PL_strdup+00030
   063CA4DC    063CA4D4    PPC   17920C2C nsMsgMIMESetConformToStandard+000DC
   063CA4CC    063CA4C4    PPC   1622AF7C PREF_GetBoolPref+00020
   063CA4BC    063CA4B4    PPC   1790BAFC
nsMsgComposeAndSend::HackAttachments(const nsMsgAtt
achmentData*, const nsMsgAttachedFile*)+00D80
   063CA46C                PPC   16416D18
nsLargeHeapAllocator::AllocatorMakeBlock(unsigned l
ong)+00038
   063CA40C                68K   1624BAEA
nsServiceManagerImpl::ReleaseService(const nsID&, n
sISupports*, nsIShutdownListener*)+00132
   063CA3CC    063CA3C4    PPC   162468F4 nsHashtable::Get(nsHashKey*)+00058
   063CA3BC    063CA3B4    PPC   166273E4 PR_CExitMonitor+00074
   063CA3B4                68K   063CA3F2
   063CA31C                PPC   1660BF28 PL_HashTableRawLookup+0005C
   063CA27C    063CA274    PPC   1790A368
nsMsgComposeAndSend::GatherMimeAttachments()+020D8
   063CA22C                68K   1628A822
nsOutputFileStream::~nsOutputFileStream()+000F6
   063CA20C    063CA204    PPC   1790C9C0
nsMsgComposeAndSend::DeliverMessage()+001E8
   063CA18C    063CA184    PPC   16414474 free+0006C
   063CA0EC    063CA0E4    PPC   FFD622F4 PBCloseSync+00028
   063CA0CC    063CA0C4    PPC   1790CE5C
nsMsgComposeAndSend::DeliverFileAsMail()+00438
   063CA08C                PPC   16275F74 nsString::nsString(const char*,
eCharSize, nsIMemor
yAgent*)+0004C
   063CA04A                68K   0010FFFC
   063C9FFC    063C9FF4    PPC   17915F54 nsSmtpService::SendMailMessage(const
nsFilePath&, c
onst nsString&, nsIUrlListener*, nsIURL**)+0021C
   063C9FC2                68K   00000596
   063C9FBA                68K   00000596
   063C9F8C    063C9F84    PPC   17916418 NS_MsgLoadMailtoUrl(nsIURL*,
nsISupports*)+00120
   063C9F74                68K   063C9FC6
   063C9EFC    063C9EF4    PPC   17915250 nsSmtpProtocol::LoadUrl(nsIURL*,
nsISupports*)+001B
C
   063C9EBC    063C9EB4    PPC   17918774
nsSmtpUrl::GetAllRecipients(char**)+00034
   063C9E9C    063C9E94    PPC   16C86CC4
nsMsgHeaderParser::RemoveDuplicateAddresses(const c
har*, const char*, const char*, int, char**)+000BC
   063C9E4C                PPC   16C69790 MIME_ConvertString+00048
   063C9DEC    063C9DE4    PPC   16C89624 msg_remove_duplicate_addresses(const
char*, const c
har*, int)+000A8
   063C9DC2                68K   00000596
   063C9D4C                PPC   16413278 operator new(unsigned long)+00018
   063C9D2C    063C9D24    PPC   162762A0 nsString::~nsString()+00030
   063C9CEC                PPC   1626E324 nsStr::Destroy(nsStr&,
nsIMemoryAgent*)+00060
   063C9CCC    063C9CC4    PPC   16C882A4 msg_parse_Header_addresses(const
char*, char**, cha
r**, int, int, int)+010B8
   063C9C3C    063C9C34    PPC   16C88B58 msg_quote_phrase_or_addr(char*, int,
int)+00618
   063C9BFC    063C9BF4    PPC   1624731C nsDebug::Assertion(const char*, const
char*, const
char*, int)+00040
   063C9BDC    063C9BD4    PPC   16414D8C
nsFixedSizeAllocator::AllocatorMakeBlock(unsigned l
ong)+000AC
   063C9BAC    063C9BA4    PPC   16414380 malloc+00088
   063C9B92                68K   0001FFFE
   063C9B70                68K   0614BA56
   063C9B6C                PPC   1626E570 nsStr::GrowCapacity(nsStr&, unsigned
int, nsIMemory
Agent*)+000A0
   063C9B4C    063C9B44    PPC   16414D8C
nsFixedSizeAllocator::AllocatorMakeBlock(unsigned l
ong)+000AC
   063C9AD0    063C9ACC    68K   0614BA56
   063C9ABC    063C9AB4    PPC   16247018 dprintf(const char*, ...)+0004C



then later, the memory has been overwritten. This is detected only during the
free...

User break at 16414EAC nsFixedSizeAllocator::AllocatorFreeBlock(void*)+0006C
 Bad block trailer

 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  2C00084A    PPC  1629C358  XPTC_InvokeByIndex+0012C
  063CAC54    PPC  179284DC  nsMsgCompose::SendMsg(int, const unsigned
short*)+006A8
  063CA9A4    PPC  17929258  nsMsgCompose::SendMsgEx(int, const unsigned short*,
const unsign
ed short*, const unsigned short*, const unsigned short*, const unsigned short*,
const unsigne
d short*, const unsigned short*)+00C88
  063CA634    PPC  1790EDE8
nsMsgComposeAndSend::CreateAndSendMessage(nsIMsgCompFields*, int
, int, nsMsgDeliverMode, const char*, const char*, unsigned int, const
nsMsgAttachmentData*,
const nsMsgAttachedFile*, void*, unsigned int (*)(unsigned int, void*,
nsFileSpec*), vo+000AC
  063CA5D4    PPC  1790C588  nsMsgComposeAndSend::Init(nsMsgCompFields*,
nsFileSpec*, int, in
t, nsMsgDeliverMode, const char*, const char*, unsigned int, const
nsMsgAttachmentData*, cons
t nsMsgAttachedFile*, nsMsgSendPart*, void*)+002C8
  063CA544    PPC  1790BAFC  nsMsgComposeAndSend::HackAttachments(const
nsMsgAttachmentData*,
 const nsMsgAttachedFile*)+00D80
  063CA4B4    PPC  1790A368  nsMsgComposeAndSend::GatherMimeAttachments()+020D8
  063CA274    PPC  1790C9C0  nsMsgComposeAndSend::DeliverMessage()+001E8
  063CA204    PPC  1790CE5C  nsMsgComposeAndSend::DeliverFileAsMail()+00438
  063CA0C4    PPC  17915F54  nsSmtpService::SendMailMessage(const nsFilePath&,
const nsString
&, nsIUrlListener*, nsIURL**)+0021C
  063C9FF4    PPC  17916418  NS_MsgLoadMailtoUrl(nsIURL*, nsISupports*)+00120
  063C9F84    PPC  17915250  nsSmtpProtocol::LoadUrl(nsIURL*,
nsISupports*)+001BC
  063C9EF4    PPC  16C86CC4  nsMsgHeaderParser::RemoveDuplicateAddresses(const
char*, const c
har*, const char*, int, char**)+000BC
  063C9E94    PPC  16C89624  msg_remove_duplicate_addresses(const char*, const
char*, int)+00
0A8
  063C9DE4    PPC  16C882A4  msg_parse_Header_addresses(const char*, char**,
char**, int, int
, int)+010B8
  063C9CC4    PPC  16C88B80  msg_quote_phrase_or_addr(char*, int, int)+00640
  063C9C34    PPC  16623470  PR_Free+00014
  063C9BF4    PPC  16414474  free+0006C

Scott MacGregor

Assignee

Comment 1

•

26 years ago

Accepting, setting TFV to M8.

Status: NEW → ASSIGNED

Target Milestone: M8

Jean-Francois Ducarroz

Comment 2

•

26 years ago

Currently we are not crashing in Mac in debug mode but it might be possible that we do with the release build as we
don't have some extra pading between each memory block allocated.

rhp (gone)

Comment 3

•

26 years ago

It may be that in the old world, the FE would never let this happen and
therefore we never saw the bug...just a guess.

- rhp

lchiang

Updated

•

26 years ago

QA Contact: lchiang → esther

lchiang

Comment 4

•

26 years ago

<Will add to release notes for M7>

lchiang

Comment 5

•

26 years ago

Do you mean recipients instead of senders in your summary and description?
There can only be one sender.

Scott MacGregor

Assignee

Comment 6

•

26 years ago

Yes I do mean recipients =). Thanks...

Scott MacGregor

Assignee

Updated

•

26 years ago

Target Milestone: M8 → M10

Scott MacGregor

Assignee

Comment 7

•

26 years ago

this is a very very rare case since it requires the user to make a 'typo' using
';'...prioritizing my bug list and pushing this after m8....

sol

Updated

•

25 years ago

Whiteboard: [PR1]

sol

Comment 8

•

25 years ago

This would be very nice to fix for PR1. While we could release note this, it
would be better to ship without known crashers.

I added a note the the Status Whiteboard to reflect the fact that this would be
good to fix for PR1.

Phil Peterson

Comment 9

•

25 years ago

Triage to M12

lchiang

Updated

•

25 years ago

Blocks: 11091

lchiang

Comment 10

•

25 years ago

(target milestone is M11 or M12 - add to mail beta tracking bug)

Phil Peterson

Updated

•

25 years ago

Target Milestone: M12 → M13

Scott MacGregor

Assignee

Updated

•

25 years ago

Status: ASSIGNED → RESOLVED

Closed: 25 years ago

Resolution: --- → FIXED

Scott MacGregor

Assignee

Comment 11

•

25 years ago

I checked in the fix for this. There was some old crufty mime code that wasn't
allocating enough bytes for a string and then walking past the end of the string.

An easy test case:
Address a messge to foo@netscapecom;foo@netscape.com
we would have corrupted memory and debug builds would have generated an
assertion stating such.

Now, with the fix you won't see the warning complaining about corrupted memory.

Note: of course this msg will bounce because ';' is not a valid delimeter for
email addresses. your supposed to use ',' but that isn't a bug it is by design.
So when the message is sent you'll get it bounced back to you.

esther

Updated

•

25 years ago

Status: RESOLVED → VERIFIED

esther

Comment 12

•

25 years ago

Using builds 2000101211m13 on win98, 2000011212m13 on linux and 2000011208 on
Mac this is fixed because I don't crash and I do get a bounce back, but should
this be the bounce back:

"The original message was received at Thu, 13 Jan 2000 09:12:50 -0800 (PST)
from dredd.mcom.com [205.217.237.54]

   ----- The following addresses had permanent fatal errors -----
<"\"\"foo\"@netscapecom;foo@netscape.com"@netscape.com>

   ----- Transcript of session follows -----
550 <"\"\"foo\"@netscapecom;foo@netscape.com"@netscape.com>... Host unknown
(Name server:
netscapecom;foo: host not found)

I will verify this as stated, but mscott let me know if the bounce back message
is correct.  Notice it doesnt' correctly state what I entered in the To: field
and when viewing the offensive header in the bounce back message it shows that I
enterend "foo\"@netscapecom;foo@netscape.com in the To: field.

Scott MacGregor

Assignee

Comment 13

•

25 years ago

Yes, this bounce back message is correct. It's exactly what you wrote except it
has been quoted in order to send it to the server. i.e. there are two '@' signs
in the email address you typed in. One of them has to be quoted. And that's why
you have the quoting characters in front of it. Thanks for verifying!

Myk Melez [:myk] [@mykmelez]

Updated

•

20 years ago

Product: MailNews → Core

Nobody; OK to take it and work on it

Updated

•

16 years ago

Product: Core → MailNews Core

Bugzilla

Quick Search

we corrupt memory if senders separated by ';'

Categories

(MailNews Core :: Backend, defect, P3)

Tracking

(Not tracked)

People

(Reporter: mscott, Assigned: mscott)

References

Details

(Whiteboard: [PR1])

Crash Data

Security

(public)

User Story

Description

Comment 1

Comment 2

Comment 3

Updated

Comment 4

Comment 5

Comment 6

Updated

Comment 7

Updated

Comment 8

Comment 9

Updated

Comment 10

Updated

Updated

Comment 11

Updated

Comment 12

Comment 13

Updated

Updated