Home page logo

oss-sec logo oss-sec mailing list archives

Re: CVE request: kernel: multiple issues in ROSE
From: Kurt Seifried <kseifried () redhat com>
Date: Tue, 27 Dec 2011 22:17:39 -0700

Ok finally got this ironed out:

-------- Original Message --------
Subject: Re: [oss-security] CVE request: kernel: multiple issues in ROSE
Date: Tue, 5 Apr 2011 11:37:37 -0400
From: Dan Rosenberg<dan.j.rosenberg () gmail com>
Reply-To: oss-security () lists openwall com
To: oss-security () lists openwall com
CC: Steven M. Christey<coley () linus mitre org>,        Josh Bressers
<bressers () redhat com>, Eugene Teo<eugene () redhat com>


This breakdown seems to make sense.  I'll do my best to break up the
issues below.

Dan, could you confirm that this breakdown makes sense?

1) buffer overflows (not validating length is<= the maximum)

1) When parsing the FAC_NATIONAL_DIGIS facilities field, it's possible
for a remote host to provide more digipeaters than expected, resulting
in heap corruption.  Check against ROSE_MAX_DIGIS to prevent
overflows, and abort facilities parsing on failure.  It looks like
this will be CVE-2011-1493.
This was assigned CVE-2011-1493, please continue to use.


facilities fields, a remote host can provide a length of greater than
20, resulting in a stack overflow of the callsign array.
2) use of negative signed integers in memcpy() and other operations where
   conversion creates a large unsigned integer, referred to as

facilities fields, a remote host can provide a length
of less than 10, resulting in an underflow in a memcpy size, causing a
kernel panic due to massive heap corruption.

Note that 2) and 3) are solved by validating a single length field, so
maybe they should be grouped together?  The above three issues were
all found by me.

For the issues 2) and 3) in FAC_CCITT_DEST_NSAP and FAC_CCITT_SRC_NSAP please use CVE-2011-4913


3) any other types of problems that aren't covered by those two?  (The
length validation checks don't always have enough context in the source

4) Ben Hutchings' fixes addressed multiple cases where the ROSE
protocol did not ensure that socket data being parsed wasn't being
read in from beyond the boundaries of the incoming socket buffer.  For
example, a received packet might provide a length field longer than
the amount of remaining data in the socket buffer.

Looking at the patch, it doesn't appear that any memory corruption
would be caused by this, since the out-of-bounds data is still
validated by the parsing code.  I'd say the impact is likely limited
to possible information disclosure, if the contents of the
out-of-bounds memory could be inferred by the behavior of the protocol
during parsing.  It's theoretically possible (but very unlikely) that
this could cause read accesses to unmapped memory, which would cause a


For this please use CVE-2011-4914


We would need separate CVE's for the issues found by Dan versus the issues
found by Ben Hutchings.

Arguably, #2 could probably be broken down further, but without enough
source code context in the patches, it's not immediately clear.

- Steve


-Kurt Seifried / Red Hat Security Response Team


-Kurt Seifried / Red Hat Security Response Team

  By Date           By Thread  

Current thread:
  • Re: CVE request: kernel: multiple issues in ROSE Kurt Seifried (Dec 28)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]