#3776: Out of bounds heap read when parsing malformed header
-+-
Reporter: hanno | Owner: brendan
Type: defect | Status: new
Priority: major | Milestone:
Component: IMAP|Version:
Resolution: | Keywords:
-
The ticket reported an out of bounds read in mutt_read_rfc822_line()
when a '\0' was embedded on its own line in the headers. The function
assumed if fgets() didn't return NULL, then the string would have at
least character.
I scanned the rest of the code and found three other places making the
s
Attaching a minor update to the patch. I fixed the ticket number and
also changed mutt_flush_macro_to_endcond() to directly manipulate
MacroEvents[] instead of using mutt_ch().
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-
On Tue, Sep 29, 2015 at 03:30:27PM +0800, Kevin J. McCarthy wrote:
> The ticket reported an out of bounds read in mutt_read_rfc822_line()
> when a '\0' was embedded on its own line in the headers. The function
> assumed if fgets() didn't return NULL, then the string would have at
> least [one] ch
On Tue, Sep 29, 2015 at 07:23:57PM +0200, Oswald Buddenhagen wrote:
> On Tue, Sep 29, 2015 at 03:30:27PM +0800, Kevin J. McCarthy wrote:
> > least [one] character.
Fixed. Thank you.
> at face value, these fragments look too optimistic - the last line could
> have no trailing newline, even if err
changeset: 6512:590ff6eebe1a
user: Kevin McCarthy
date: Wed Sep 30 11:21:06 2015 +0800
link: http://dev.mutt.org/hg/mutt/rev/590ff6eebe1a
Fix oob reads when fgets returns "\0". (closes #3776)
The ticket reported an out of bounds read in mutt_read_rfc822_line()
when a '\0' was emb
#3776: Out of bounds heap read when parsing malformed header
-+-
Reporter: hanno | Owner: brendan
Type: defect | Status: closed
Priority: major | Milestone:
Component: IMAP|Version:
Resolution: fixed | Keywords:
--
On Wed, Sep 30, 2015 at 10:51:30AM +0800, Kevin J. McCarthy wrote:
> On Tue, Sep 29, 2015 at 07:23:57PM +0200, Oswald Buddenhagen wrote:
> > at face value, these fragments look too optimistic - the last line could
> > have no trailing newline, even if erroneously. not sure if that can
> > actually