summaryrefslogtreecommitdiffstats
path: root/arch/arm/mm/copypage-v3.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2012-04-15 17:23:00 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2012-04-15 17:23:00 -0700
commit12e993b89464707398e4209bd99983e376454985 (patch)
tree1cf84a342cb63bf3c89c4b9a1f1d49a9f65f35ed /arch/arm/mm/copypage-v3.c
parentebfc5b802fa76baeb4371311ff9fc27a2258d90d (diff)
x86-32: fix up strncpy_from_user() sign error
The 'max' range needs to be unsigned, since the size of the user address space is bigger than 2GB. We know that 'count' is positive in 'long' (that is checked in the caller), so we will truncate 'max' down to something that fits in a signed long, but before we actually do that, that comparison needs to be done in unsigned. Bug introduced in commit 92ae03f2ef99 ("x86: merge 32/64-bit versions of 'strncpy_from_user()' and speed it up"). On x86-64 you can't trigger this, since the user address space is much smaller than 63 bits, and on x86-32 it works in practice, since you would seldom hit the strncpy limits anyway. I had actually tested the corner-cases, I had only tested them on x86-64. Besides, I had only worried about the case of a pointer *close* to the end of the address space, rather than really far away from it ;) This also changes the "we hit the user-specified maximum" to return 'res', for the trivial reason that gcc seems to generate better code that way. 'res' and 'count' are the same in that case, so it really doesn't matter which one we return. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/arm/mm/copypage-v3.c')
0 files changed, 0 insertions, 0 deletions