jorgelo or leecam can you help identify what needs to be done here?

Backport http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=637b58c2887e5e57850865839cc75f59184b23d1 and  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=637b58c2887e5e57850865839cc75f59184b23d1 to those kernels?

I'm reliably informed that mdempsky@ is handling kernel bugs.

olofj (and amstan/dgreid): For  crbug.com/588862 , your team handled preparing the CLs for the applicable kernel trees, and I just handled security reviewing them.  Did that approach work for you?  Can we do that again here?

FWIW, I agree with Jorge about just backporting upstreams fixes.  (The first CL link should be http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f0d1bec9d58d4c038d0ac958c9af82be6eb18045 though.)

So...

In general, the approach we've had is that the security team makes us aware of the bug, and ideally what the known remedy is. I.e. what Vomit usually spits out in the first place. For P2/P3, we usually keep them around for someone to take care of on an idle loop or for nooglers to get familiar with our environment.

Ideally, whomever can get to it first on P0/P1 issues should do it but we (from kernel) usually expect security team to make sure they're not lost or dropped.

It might mean security team preparing the patch, and someone from kernel team reviewing. If we're preparing the patch, often we can also review it but of course we're happy to spread the load -- in particular if it was a nontrivial backport or in an area where we've done other modifications for security, etc.

Also, it might be in the security team's interest to do a testcase for this. We've done that for some bugs but not all, and it's usually been security team that traditionally has driven that effort.

In this case I'm happy to perfcrastinate a bit and prepare them. I'll hash out with Justin what our standard model should be going forward though so we stick to one flow of ownership.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fa681a9efffe4169d321eb4be6b6ac44be33e838

commit fa681a9efffe4169d321eb4be6b6ac44be33e838
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.10 -stable commit 14f81062f365fa9e3839bb2a16862217b71a553c)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I8df1cb7f02f4b4ab626999a211b8fde3890eab5b
Reviewed-on: https://chromium-review.googlesource.com/334830
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Matthew Dempsky <mdempsky@chromium.org>

[modify] https://crrev.com/fa681a9efffe4169d321eb4be6b6ac44be33e838/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0dc29b39558c74b6469ad438ef4cf8c1273367b6

commit 0dc29b39558c74b6469ad438ef4cf8c1273367b6
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.14 -stable commit 6b17faf3d5fa6a727c40613bdf24d73b2a59df27)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I2ddc18ac3ceab6b5ce916c6e6484a1b23afde470
Reviewed-on: https://chromium-review.googlesource.com/334733
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Matthew Dempsky <mdempsky@chromium.org>

[modify] https://crrev.com/0dc29b39558c74b6469ad438ef4cf8c1273367b6/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6e291678522f4b335fb3589969f0c3657eacc43f

commit 6e291678522f4b335fb3589969f0c3657eacc43f
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.10 -stable commit 14f81062f365fa9e3839bb2a16862217b71a553c)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I7425195f3f3bc6543d1607bef7030c2d491f1e9a
Reviewed-on: https://chromium-review.googlesource.com/334752
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Matthew Dempsky <mdempsky@chromium.org>

[modify] https://crrev.com/6e291678522f4b335fb3589969f0c3657eacc43f/fs/pipe.c

> Only users with SecurityTeam permission can see this issue.

Josafat - can the TPMs responsible for approving my merge requests see the Restrict-View-SecurityTeam issues?

yes, the TPMs can see these issues.

Please mark security bugs as fixed as soon as the fix lands, and before requesting merges.

- Your friendly ClusterFuzz

[Automated comment] Request affecting a post-stable build (M49), manual review required.

Your change meets the bar and is auto-approved for M50 (branch: 2661)

[Automated comment] Request affecting a post-stable build (M49), manual review required.

Hi guys, still need manual approval to merge this to M49.  I have the patches all queued up, whenever you're ready.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f46f39a5be9e30790d2e4911b0345eb500530a6c

commit f46f39a5be9e30790d2e4911b0345eb500530a6c
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.14 -stable commit 6b17faf3d5fa6a727c40613bdf24d73b2a59df27)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I2ddc18ac3ceab6b5ce916c6e6484a1b23afde470
Previous-Reviewed-on: https://chromium-review.googlesource.com/334733
(cherry picked from commit 743ca89d0805f8903745ac5f7380f833b0b1821f)
Reviewed-on: https://chromium-review.googlesource.com/336699
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/f46f39a5be9e30790d2e4911b0345eb500530a6c/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9c6593a30cf8a9245c9490446a70d8ac6ac441fb

commit 9c6593a30cf8a9245c9490446a70d8ac6ac441fb
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.10 -stable commit 14f81062f365fa9e3839bb2a16862217b71a553c)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I7425195f3f3bc6543d1607bef7030c2d491f1e9a
Previous-Reviewed-on: https://chromium-review.googlesource.com/334752
(cherry picked from commit a28df0ce64a203096bd5ea4879ae353d95d0260e)
Reviewed-on: https://chromium-review.googlesource.com/336698
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/9c6593a30cf8a9245c9490446a70d8ac6ac441fb/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d4a1ddbfcfa85def25206657766765c549becf41

commit d4a1ddbfcfa85def25206657766765c549becf41
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.10 -stable commit 14f81062f365fa9e3839bb2a16862217b71a553c)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I8df1cb7f02f4b4ab626999a211b8fde3890eab5b
Previous-Reviewed-on: https://chromium-review.googlesource.com/334830
(cherry picked from commit 476af4cc415ace64b06f94bbf0c77336abbf1bda)
Reviewed-on: https://chromium-review.googlesource.com/335321
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/d4a1ddbfcfa85def25206657766765c549becf41/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/afbdf36af4809a661913ff1aff44de6fd6bd2686

commit afbdf36af4809a661913ff1aff44de6fd6bd2686
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.10 -stable commit 14f81062f365fa9e3839bb2a16862217b71a553c)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I7425195f3f3bc6543d1607bef7030c2d491f1e9a
Previous-Reviewed-on: https://chromium-review.googlesource.com/334752
(cherry picked from commit c482bda1ce47bb9321216ad6fb1bfd8eac077a82)
Reviewed-on: https://chromium-review.googlesource.com/335300
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/afbdf36af4809a661913ff1aff44de6fd6bd2686/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/df0ab86b29c09ef576bbd3074ae5d70f305fd0f5

commit df0ab86b29c09ef576bbd3074ae5d70f305fd0f5
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Jun 16 21:11:06 2015

UPSTREAM: pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from 3.10 -stable commit 14f81062f365fa9e3839bb2a16862217b71a553c)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I8df1cb7f02f4b4ab626999a211b8fde3890eab5b
Previous-Reviewed-on: https://chromium-review.googlesource.com/334830
(cherry picked from commit 151c8a8404b73ba2c31f1808f0bc7378496b1870)
Reviewed-on: https://chromium-review.googlesource.com/336713
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/df0ab86b29c09ef576bbd3074ae5d70f305fd0f5/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/004cb7a4dc8e4fd1cf3b67360e406d506520a02f

commit 004cb7a4dc8e4fd1cf3b67360e406d506520a02f
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: Id50e309db9f631da1693ce57a89f506aea512165
Reviewed-on: https://chromium-review.googlesource.com/336891
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Matthew Dempsky <mdempsky@chromium.org>

[modify] https://crrev.com/004cb7a4dc8e4fd1cf3b67360e406d506520a02f/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/74aaf81c5481eb87589595164acb6eb03e33b195

commit 74aaf81c5481eb87589595164acb6eb03e33b195
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I73d873bbd0de3ce473422d5587fa35b60fe35f3a
Reviewed-on: https://chromium-review.googlesource.com/336882
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Matthew Dempsky <mdempsky@chromium.org>

[modify] https://crrev.com/74aaf81c5481eb87589595164acb6eb03e33b195/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9c242cb35237f3c6c737b376ed18545fc4e1be0c

commit 9c242cb35237f3c6c737b376ed18545fc4e1be0c
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I0c777fabffb418e9b4e33da0e65e378110fb6f45
Reviewed-on: https://chromium-review.googlesource.com/336833
Commit-Ready: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Matthew Dempsky <mdempsky@chromium.org>

[modify] https://crrev.com/9c242cb35237f3c6c737b376ed18545fc4e1be0c/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6666f1acde957d673703914c2dfeda5610477143

commit 6666f1acde957d673703914c2dfeda5610477143
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I73d873bbd0de3ce473422d5587fa35b60fe35f3a
Previous-Reviewed-on: https://chromium-review.googlesource.com/336882
(cherry picked from commit 9bc06faa4ee088831b097d3429ba0fa0c1007561)
Reviewed-on: https://chromium-review.googlesource.com/336868
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/6666f1acde957d673703914c2dfeda5610477143/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a54e8cbc3726a3fcc1fe1a58825b00f61996c0e5

commit a54e8cbc3726a3fcc1fe1a58825b00f61996c0e5
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: Id50e309db9f631da1693ce57a89f506aea512165
Previous-Reviewed-on: https://chromium-review.googlesource.com/336891
(cherry picked from commit c7fafbdfcf9ffd7ef0a3085e49fd627884a08be9)
Reviewed-on: https://chromium-review.googlesource.com/336900
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/a54e8cbc3726a3fcc1fe1a58825b00f61996c0e5/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/38cca09054d29683d61724d2766ef1913fb037cb

commit 38cca09054d29683d61724d2766ef1913fb037cb
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I73d873bbd0de3ce473422d5587fa35b60fe35f3a
Previous-Reviewed-on: https://chromium-review.googlesource.com/336882
(cherry picked from commit c5b20ce166d4ae47d096e3b2f74952c844b157bd)
Reviewed-on: https://chromium-review.googlesource.com/336859
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/38cca09054d29683d61724d2766ef1913fb037cb/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/58e0cb41090151f13fd590b052a7496381b75875

commit 58e0cb41090151f13fd590b052a7496381b75875
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I0c777fabffb418e9b4e33da0e65e378110fb6f45
Previous-Reviewed-on: https://chromium-review.googlesource.com/336833
(cherry picked from commit 24142fcc8b599825f40b37765260e834943d12cb)
Reviewed-on: https://chromium-review.googlesource.com/336858
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/58e0cb41090151f13fd590b052a7496381b75875/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dc5d6e4ec976fa861a6b7a890c4b992f0bbe2ae7

commit dc5d6e4ec976fa861a6b7a890c4b992f0bbe2ae7
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: I0c777fabffb418e9b4e33da0e65e378110fb6f45
Previous-Reviewed-on: https://chromium-review.googlesource.com/336833
(cherry picked from commit e1ba2a5d7ae97a71aa96b202d301653cb41f1f48)
Reviewed-on: https://chromium-review.googlesource.com/336869
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/dc5d6e4ec976fa861a6b7a890c4b992f0bbe2ae7/fs/pipe.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/37f6bbff8c2c122922a4ed531d729b9669739e0a

commit 37f6bbff8c2c122922a4ed531d729b9669739e0a
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sat Feb 13 02:34:52 2016

UPSTREAM: pipe: Fix buffer offset after partially failed read

Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from 3.2 -stable commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>

BUG= chromium:597333 
TEST=buildbots

Change-Id: Id50e309db9f631da1693ce57a89f506aea512165
Previous-Reviewed-on: https://chromium-review.googlesource.com/336891
(cherry picked from commit da314acdee24d428ce0d37e078e9274a4f21b1a7)
Reviewed-on: https://chromium-review.googlesource.com/336892
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Kevin Cernekee <cernekee@chromium.org>
Tested-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/37f6bbff8c2c122922a4ed531d729b9669739e0a/fs/pipe.c

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Bulk verified

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot