Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Jun 2015 14:26:39 +0300
From: Solar Designer <>
Subject: Re: CVE-2015-1805 Linux kernel: pipe: iovec overrun leading to memory corruption

On Sat, Jun 06, 2015 at 02:30:57PM +0300, Solar Designer wrote:
> The possibility of "struct iovec *iov" going out of range and the
> subsequent out of bounds metadata accesses feel much more severe than
> the out of bounds accesses to actual data in the userspace.
> "iov->iov_base += copy;" and "iov->iov_len -= copy;" might then be
> corrupting kernel memory.  It feels relatively unimportant what the
> resulting values of iov_base and iov_len will be for their intended
> purpose, since we use copy_from_user() / copy_to_user() on them anyway.
> It feels more important that these "+=" and "-=" operators directly
> modify individual words in kernel memory, albeit only slightly(?) out of
> bounds of the original iov array.  So maybe it's this risk that needs
> to be evaluated further.

Upon a closer look, it appears that this is in fact the impact Red Hat
had in mind as well.  I was not reading closely enough.  The "Doc Text"
field at says:

"It was found that the Linux kernel's implementation of vectored pipe
read and write functionality did not take into account the I/O vectors
that were already processed when retrying after a failed atomic access
operation, potentially resulting in memory corruption due to an I/O
vector array overrun."

So we're on the same page regarding "I/O vector array overrun" (rather
than I/O data overrun) being the security issue here.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.