Bug 1608539 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The subject says it all
|m_headerstartpos| is not always initialized in nsParseMailMessageState::FinalizeHeaders() 

The unitinitialized reference happens at
https://searchfox.org/comm-central/source/mailnews/local/src/nsParseMailbox.cpp#1223

I found this by running xpcshell-tests under valgrind.

If m_headerstartpos is not properly initialized, literally anything goes. 
Header parsing, etc. get all screwed up.

The symptom of strange display of message in a message pane that shows only blank or in the middle of header, etc. could be at least partially explained by this bug. (Maybe not all the cases.)

I detected the issue using valgrind,  and then began dumping m_headerstartpos after I set
```
export MALLOC_CHECK_=3
export MALLOC_PERTURB_=0x5A
```
in my environment. GNU libc malloc fills the uninitialized malloc'ed area with 0xA5.
Thus it is rather easy to find it in an otherwise normal dump.
```
cf. From man mallopt.

       M_PERTURB (since glibc 2.4)
              If this parameter is set to a nonzero value, then bytes of allocated memory  (other  than  alloca‐
              tions  via calloc(3)) are initialized to the complement of the value in the least significant byte
              of value, and when allocated memory is released using free(3), the freed  bytes  are  set  to  the
              least  significant  byte  of value.  This can be useful for detecting errors where programs incor‐
              rectly rely on allocated memory being initialized to zero, or reuse values in memory that has  al‐
              ready been freed.
   ...
       MALLOC_PERTURB_
              Controls the same parameter as mallopt() M_PERTURB.

```
The tests that trigger and not trigger the symptoms in C-C portion of xpcshell-tests are as follows.
This is the output from egrep "(nrun-xpcshell-original.sh|a5a5a5a5)" log1155-xpcshell.txt
log1155-xpcshell.txt being the log output.

```
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/components/src/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/modules/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/protocols/irc/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/protocols/skype/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/protocols/xmpp/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/common/saxparser/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/common/test/xpcshell
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/ldap/xpcom/tests/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/base/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/components/enterprisepolicies/tests/xpcshell
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/components/extensions/test/xpcshell
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/components/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/addrbook/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/base/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/compose/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/db/gloda/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/db/msgdb/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/extensions/bayesian-spam-filter/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/extensions/mdn/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/extensions/newsblog/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/imap/test/unit
 1:14.92 pid:109013 (debug) VALGRIND: m_headerstartpos = 0xa5a5a5a5a5a5a5a5, mozstatus->value =0x0x55788019a046,m_headers.GetBuffer()=0x557880199fe0, m_envelope_pos=0x0
 2:17.25 pid:110314 (debug) VALGRIND: m_headerstartpos = 0xa5a5a5a5a5a5a5a5, mozstatus->value =0x0x557082978326,m_headers.GetBuffer()=0x5570829782c0, m_envelope_pos=0x0
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/import/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/intl/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/jsaccount/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/local/test/unit
 0:09.37 pid:111723 (debug) VALGRIND: m_headerstartpos = 0xa5a5a5a5a5a5a5a5, mozstatus->value =0x0x5645cf9c8621,m_headers.GetBuffer()=0x5645cf9c85b0, m_envelope_pos=0x0
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/mime/jsmime/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/mime/test/unit

```
I inserted the dump of m_headerstartpos in the attached file.


I have not fully analyzed WHEN/HOW the uninitialized access happens. But I suspect this has something to do with malformed or missing headers.
I don't want to see some script kiddies sending out such messages en masse to disrupt TB users, thus setting the security flag.
Once we can be sure this is of minor issue, then we can unflag it.

TIA
The subject says it all
|m_headerstartpos| is not always initialized in nsParseMailMessageState::FinalizeHeaders() 

The unitinitialized reference happens at
https://searchfox.org/comm-central/source/mailnews/local/src/nsParseMailbox.cpp#1223

I found this by running xpcshell-tests under valgrind.

If m_headerstartpos is not properly initialized, literally anything goes. 
Header parsing, etc. get all screwed up.

The symptom of strange display of message in a message pane that shows only blank or in the middle of header, etc. could be at least partially explained by this bug. (Maybe not all the cases.)

I detected the issue using valgrind,  and then began dumping m_headerstartpos after I set
```
export MALLOC_CHECK_=3
export MALLOC_PERTURB_=0x5A
```
in my environment. GNU libc malloc fills the uninitialized malloc'ed area with 0xA5.
Thus it is rather easy to find it in an otherwise normal dump.
```
cf. From man mallopt.

       M_PERTURB (since glibc 2.4)
              If this parameter is set to a nonzero value, then bytes of allocated memory  (other  than  alloca‐
              tions  via calloc(3)) are initialized to the complement of the value in the least significant byte
              of value, and when allocated memory is released using free(3), the freed  bytes  are  set  to  the
              least  significant  byte  of value.  This can be useful for detecting errors where programs incor‐
              rectly rely on allocated memory being initialized to zero, or reuse values in memory that has  al‐
              ready been freed.
   ...
       MALLOC_PERTURB_
              Controls the same parameter as mallopt() M_PERTURB.

```
The tests that trigger and not trigger the symptoms in C-C portion of xpcshell-tests are as follows.
This is the output from egrep "(nrun-xpcshell-original.sh|a5a5a5a5)" log1155-xpcshell.txt
log1155-xpcshell.txt being the log output.

```
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/components/src/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/modules/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/protocols/irc/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/protocols/skype/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/chat/protocols/xmpp/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/common/saxparser/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/common/test/xpcshell
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/ldap/xpcom/tests/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/base/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/components/enterprisepolicies/tests/xpcshell
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/components/extensions/test/xpcshell
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mail/components/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/addrbook/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/base/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/compose/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/db/gloda/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/db/msgdb/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/extensions/bayesian-spam-filter/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/extensions/mdn/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/extensions/newsblog/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/imap/test/unit
 1:14.92 pid:109013 (debug) VALGRIND: m_headerstartpos = 0xa5a5a5a5a5a5a5a5, mozstatus->value =0x0x55788019a046,m_headers.GetBuffer()=0x557880199fe0, m_envelope_pos=0x0
 2:17.25 pid:110314 (debug) VALGRIND: m_headerstartpos = 0xa5a5a5a5a5a5a5a5, mozstatus->value =0x0x557082978326,m_headers.GetBuffer()=0x5570829782c0, m_envelope_pos=0x0
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/import/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/intl/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/jsaccount/test/unit
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/local/test/unit
 0:09.37 pid:111723 (debug) VALGRIND: m_headerstartpos = 0xa5a5a5a5a5a5a5a5, mozstatus->value =0x0x5645cf9c8621,m_headers.GetBuffer()=0x5645cf9c85b0, m_envelope_pos=0x0
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/mime/jsmime/test
+ bash -vx /home/ishikawa/bin/nrun-xpcshell-original.sh --sequential --verbose comm/mailnews/mime/test/unit

```
I inserted the dump of m_headerstartpos using the patch in the attached file.


I have not fully analyzed WHEN/HOW the uninitialized access happens. But I suspect this has something to do with malformed or missing headers.
I don't want to see some script kiddies sending out such messages en masse to disrupt TB users, thus setting the security flag.
Once we can be sure this is of minor issue, then we can unflag it.

TIA

Back to Bug 1608539 Comment 0