From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, James Cowgill <James.Cowgill@imgtec.com>,
David Daney <david.daney@cavium.com>,
James Hogan <james.hogan@imgtec.com>,
Ralf Baechle <ralf@linux-mips.org>,
linux-mips@linux-mips.org
Subject: [PATCH 4.10 004/167] MIPS: OCTEON: Fix copy_from_user fault handling for large buffers
Date: Fri, 10 Mar 2017 10:07:27 +0100 [thread overview]
Message-ID: <20170310083957.093491314@linuxfoundation.org> (raw)
In-Reply-To: <20170310083956.767605269@linuxfoundation.org>
4.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Cowgill <James.Cowgill@imgtec.com>
commit 884b426917e4b3c85f33b382c792a94305dfdd62 upstream.
If copy_from_user is called with a large buffer (>= 128 bytes) and the
userspace buffer refers partially to unreadable memory, then it is
possible for Octeon's copy_from_user to report the wrong number of bytes
have been copied. In the case where the buffer size is an exact multiple
of 128 and the fault occurs in the last 64 bytes, copy_from_user will
report that all the bytes were copied successfully but leave some
garbage in the destination buffer.
The bug is in the main __copy_user_common loop in octeon-memcpy.S where
in the middle of the loop, src and dst are incremented by 128 bytes. The
l_exc_copy fault handler is used after this but that assumes that
"src < THREAD_BUADDR($28)". This is not the case if src has already been
incremented.
Fix by adding an extra fault handler which rewinds the src and dst
pointers 128 bytes before falling though to l_exc_copy.
Thanks to the pwritev test from the strace test suite for originally
highlighting this bug!
Fixes: 5b3b16880f40 ("MIPS: Add Cavium OCTEON processor support ...")
Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
Acked-by: David Daney <david.daney@cavium.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14978/
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/cavium-octeon/octeon-memcpy.S | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/arch/mips/cavium-octeon/octeon-memcpy.S
+++ b/arch/mips/cavium-octeon/octeon-memcpy.S
@@ -208,18 +208,18 @@ EXC( STORE t2, UNIT(6)(dst), s_exc_p10u)
ADD src, src, 16*NBYTES
EXC( STORE t3, UNIT(7)(dst), s_exc_p9u)
ADD dst, dst, 16*NBYTES
-EXC( LOAD t0, UNIT(-8)(src), l_exc_copy)
-EXC( LOAD t1, UNIT(-7)(src), l_exc_copy)
-EXC( LOAD t2, UNIT(-6)(src), l_exc_copy)
-EXC( LOAD t3, UNIT(-5)(src), l_exc_copy)
+EXC( LOAD t0, UNIT(-8)(src), l_exc_copy_rewind16)
+EXC( LOAD t1, UNIT(-7)(src), l_exc_copy_rewind16)
+EXC( LOAD t2, UNIT(-6)(src), l_exc_copy_rewind16)
+EXC( LOAD t3, UNIT(-5)(src), l_exc_copy_rewind16)
EXC( STORE t0, UNIT(-8)(dst), s_exc_p8u)
EXC( STORE t1, UNIT(-7)(dst), s_exc_p7u)
EXC( STORE t2, UNIT(-6)(dst), s_exc_p6u)
EXC( STORE t3, UNIT(-5)(dst), s_exc_p5u)
-EXC( LOAD t0, UNIT(-4)(src), l_exc_copy)
-EXC( LOAD t1, UNIT(-3)(src), l_exc_copy)
-EXC( LOAD t2, UNIT(-2)(src), l_exc_copy)
-EXC( LOAD t3, UNIT(-1)(src), l_exc_copy)
+EXC( LOAD t0, UNIT(-4)(src), l_exc_copy_rewind16)
+EXC( LOAD t1, UNIT(-3)(src), l_exc_copy_rewind16)
+EXC( LOAD t2, UNIT(-2)(src), l_exc_copy_rewind16)
+EXC( LOAD t3, UNIT(-1)(src), l_exc_copy_rewind16)
EXC( STORE t0, UNIT(-4)(dst), s_exc_p4u)
EXC( STORE t1, UNIT(-3)(dst), s_exc_p3u)
EXC( STORE t2, UNIT(-2)(dst), s_exc_p2u)
@@ -383,6 +383,10 @@ done:
nop
END(memcpy)
+l_exc_copy_rewind16:
+ /* Rewind src and dst by 16*NBYTES for l_exc_copy */
+ SUB src, src, 16*NBYTES
+ SUB dst, dst, 16*NBYTES
l_exc_copy:
/*
* Copy bytes from src until faulting load address (or until a
next prev parent reply other threads:[~2017-03-10 9:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170310083956.767605269@linuxfoundation.org>
2017-03-10 9:07 ` [PATCH 4.10 001/167] MIPS: pic32mzda: Fix linker error for pic32_get_pbclk() Greg Kroah-Hartman
2017-03-10 9:07 ` [PATCH 4.10 003/167] MIPS: BCM47XX: Fix button inversion for Asus WL-500W Greg Kroah-Hartman
2017-03-10 9:07 ` Greg Kroah-Hartman [this message]
2017-03-10 9:07 ` [PATCH 4.10 005/167] MIPS: Lantiq: Keep ethernet enabled during boot Greg Kroah-Hartman
2017-03-10 9:07 ` [PATCH 4.10 006/167] MIPS: Clear ISA bit correctly in get_frame_info() Greg Kroah-Hartman
2017-03-10 9:07 ` [PATCH 4.10 007/167] MIPS: Prevent unaligned accesses during stack unwinding Greg Kroah-Hartman
2017-03-10 9:07 ` [PATCH 4.10 008/167] MIPS: Fix get_frame_info() handling of microMIPS function size Greg Kroah-Hartman
2017-03-10 9:07 ` [PATCH 4.10 009/167] MIPS: Fix is_jump_ins() handling of 16b microMIPS instructions Greg Kroah-Hartman
2017-03-10 9:07 ` [PATCH 4.10 010/167] MIPS: Calculate microMIPS ra properly when unwinding the stack Greg Kroah-Hartman
2017-03-10 9:07 ` [PATCH 4.10 011/167] MIPS: Handle microMIPS jumps in the same way as MIPS32/MIPS64 jumps Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170310083957.093491314@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=James.Cowgill@imgtec.com \
--cc=david.daney@cavium.com \
--cc=james.hogan@imgtec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox