125517 - segmentation fault on retrieving data

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Jan Ludewig]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020120
BuildID:    20020202

Sending an ascii-string to the browser without mime-type causes mozilla to crash
with a segmentation fault if that strings contains the
character sequence '(https)'.




Reproducible: Always
Steps to Reproduce:
1. Create a file like this:
<content>foofoo (https)</content>
2. Make this file to be sent to the browser (I used /bin/cat in inetd.conf for
the service 'http')
3. Request it with mozilla

Actual Results:  Mozilla crashes with a segmentation fault.

Expected Results:  Display the file as plain text.

a) It crashes only if there are enough characters that precede the '(https)'
b) It does not crash, if the string in brackets is not 'https'.
c) It has been verified on windows as well.
d) The buildID is wrong, mine is not displayed, but the bug has been verified by
various people in IRC.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

Stack trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1026 (LWP 5583)]
0x4069d500 in memchr () at ../../../dist/include/xpcom/nsCOMPtr.h:410
410
      NS_EXPORT ~nsCOMPtr_base() { }
(gdb) bt
#0  0x4069d500 in memchr () at ../../../dist/include/xpcom/nsCOMPtr.h:410
#1  0x40cb72bc in nsHttpConnection::nsIStreamListener virtual table () at
../../../dist/include/xpcom/nsCOMPtr.h:410
#2  0x40c3cb57 in nsHttpTransaction::Read (this=0x8695a38, buf=0x42200fd0
"foofoo (https)\n", count=15, bytesWritten=0xbf7ff840)
    at /part2/mozilla/netwerk/protocol/http/src/nsHttpTransaction.cpp:866
#3  0x40200fa4 in nsReadFromInputStream (outStr=0x869293c, closure=0x8695a40,
toRawSegment=0x42200fd0 "foofoo (https)\n", offset=0, 
    count=4096, readCount=0xbf7ff840) at /part2/mozilla/xpcom/io/nsPipe2.cpp:847
#4  0x40200af3 in nsPipe::nsPipeOutputStream::WriteSegments (this=0x869293c, 
    reader=0x40200f80 <nsReadFromInputStream(nsIOutputStream *, void *, char *,
unsigned int, unsigned int, unsigned int *)>, 
    closure=0x8695a40, count=16384, writeCount=0xbf7ff924) at
/part2/mozilla/xpcom/io/nsPipe2.cpp:721
#5  0x40200fe2 in nsPipe::nsPipeOutputStream::WriteFrom (this=0x869293c,
fromStream=0x8695a40, count=16384, writeCount=0xbf7ff924)
    at /part2/mozilla/xpcom/io/nsPipe2.cpp:855
#6  0x40c02d16 in nsStreamListenerProxy::OnDataAvailable (this=0x86949e0,
request=0x8695a3c, context=0x0, source=0x8695a40, offset=0, 
    count=16384) at /part2/mozilla/netwerk/base/src/nsStreamListenerProxy.cpp:303
#7  0x40c3b0fc in nsHttpTransaction::OnDataReadable (this=0x8695a38, is=0x422006b0)
    at /part2/mozilla/netwerk/protocol/http/src/nsHttpTransaction.cpp:241
#8  0x40c3a1bb in nsHttpConnection::OnDataAvailable (this=0x42200b78,
request=0x42200d60, context=0x0, inputStream=0x422006b0, offset=0, 
    count=8192) at /part2/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp:697
#9  0x40bfd802 in nsSocketReadRequest::OnRead (this=0x42200d60) at
/part2/mozilla/netwerk/base/src/nsSocketTransport.cpp:2871
#10 0x40bf8517 in nsSocketTransport::doReadWrite (this=0x42200c28, aSelectFlags=1)
    at /part2/mozilla/netwerk/base/src/nsSocketTransport.cpp:1077
#11 0x40bf70d8 in nsSocketTransport::Process (this=0x42200c28, aSelectFlags=1)
at /part2/mozilla/netwerk/base/src/nsSocketTransport.cpp:541
#12 0x40bfed65 in nsSocketTransportService::Run (this=0x8123758) at
/part2/mozilla/netwerk/base/src/nsSocketTransportService.cpp:516
#13 0x402253d0 in nsThread::Main (arg=0x8133518) at
/part2/mozilla/xpcom/threads/nsThread.cpp:120
#14 0x403079c2 in _pt_root (arg=0x812d8f8) at
/part2/mozilla/nsprpub/pr/src/pthreads/ptthread.c:214
#15 0x4032fe24 in pthread_start_thread_event (arg=0xbf7ffc00) at manager.c:274

Comment 2

[Thomas Deniau]

Works for me 0.9.8 / Mac OS X CFM

Comment 3

[Matthias Versen [:Matti]]

-> Networking

Comment 4

[Tom Everingham]

are either of you still seeing this?  With my first attempt at reproducing it
seems  to be working.

Comment 5

[benc]

reporter:

Can you provide more information about how you did this? Are you saying that you
hacked your inetd config so that the file would be cat'd into a request on HTTP? 

You should post your file as an attachment in bugzilla (and/or) check the
content on a web server.

Thomas: thanks for the Mac data.

tever: what platform did you check?

Comment 6

[benc]

reporter: we are going to need more information to assign the bug to an engineer

Please update w/ RC1 data, and answer the questions above.

Comment 7

[benc]

status changed to reflect need to check popular platforms.

If you can get someone to confirm they have this problem on other platforms, you
increase the chance of a fix.

Comment 8

[benc]

neeti: this needs to be analyzed.

mail from reporter:

On Fri, Apr 26, 2002 at 09:26:46AM -0700, Benjamin Chuang wrote:

> >to comment 5:
> > - Yes, i hacked inetd.conf to 'cat' the file as data to be sent on all
> > established tcp connections to port 80. The application level protocol
> > used over this tcp connection does not matter at all. All data sent by the
> > client is ignored.
> >

> That is because you cannot just present the file via cat. You have to 
> include HTTP headers in the response.


Some definitions of 'hacking' say it is 'using things in another way than 
the intended one' ;)


> Can you post detailed steps as to how you configured this service, as 
> well as the file you actually sent that caused a crash?


Server Setup:
=============
a) Jail on a i686 FreeBSD Box with 4.5 Release kernel and 4.4 Release userland.
b) i686 FreeBSD-Current Box

#### /etc/inetd.conf:
http    stream  tcp     nowait  root    /bin/cat cat /NO_HTTP{NEWLINE}
####

### /NO_HTTP (also via: http://archiv.infopeace.de/jl/NO_HTTP_Mozilla.crash)
secure connection only (https){NEWLINE}{EOF}
###
(with newlines and eof visualized => omit  /{[^}]+}/)

Reproduce:
==========
1) edit inetd.conf as shown above
2) create /NO_HTTP as shown above
3) start inetd
4) point mozilla to the host and port our 'customized service' listens to.


> If this was not a crash, I really would not care, but I think the WFM 
> people have not been doing what you have been doing.

Well, insufficient input validation still seems to be the holy grail of 
morology :(

Comment 9

[neeti]

cc'ing darin

Comment 10

[benc]

neeti: please update the owner and qa when you move a bug to a new 
component.

Comment 11

[Darin Fisher]

some code changes went in since 2/14 that might have cleared up this crash.  can
someone confirm this crash with a recent nightly build?  thx!

Comment 12

[Darin Fisher]

WFM (build 1.0.0-20020514 linux)

Comment 13

[benc]

qa to me. (sigh)