[PATCH RFC] [X86] Fix potential issue on memmove
in [Kernel]
|
Prev: perf, x86: try to handle unknown nmis with running perfctrs
Next: [GIT PULL] s390 patches for 2.6.35+
From: ling.ma on 10 Aug 2010 04:20 From: Ma Ling <ling.ma(a)intel.com> memmove allow source and destination address to be overlap, but no limitation for memcpy. So memmove use forward or backward copy mode to handle src > dest and dest > src cases respectively. However memcpy has not address overlap, it may use any copy mode theoretically. Our original memmove will call memcpy and assume it must use forward copy mode, otherwise the system will crash, it is potential issue. The patch avoid assumption, meanwhile re-active patch id a1e5278e40f16a4611264f8da9e557c16cb6f6ed, which will use forward/backward copy mode according to offset address. Signed-off-by: Ma Ling <ling.ma(a)intel.com> --- arch/x86/lib/memcpy_32.c | 4 +++- arch/x86/lib/memmove_64.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/lib/memcpy_32.c b/arch/x86/lib/memcpy_32.c index 5415a9d..4f56139 100644 --- a/arch/x86/lib/memcpy_32.c +++ b/arch/x86/lib/memcpy_32.c @@ -25,7 +25,9 @@ void *memmove(void *dest, const void *src, size_t n) int d0, d1, d2; if (dest < src) { - memcpy(dest, src, n); + int i; + for(i = 0; i < n; i++) + *((char *)dest + i) = *((char *)src + i); } else { __asm__ __volatile__( "std\n\t" diff --git a/arch/x86/lib/memmove_64.c b/arch/x86/lib/memmove_64.c index 0a33909..0dded09 100644 --- a/arch/x86/lib/memmove_64.c +++ b/arch/x86/lib/memmove_64.c @@ -9,7 +9,9 @@ void *memmove(void *dest, const void *src, size_t count) { if (dest < src) { - return memcpy(dest, src, count); + int i; + for(i = 0; i < count; i++) + *((char *)dest + i) = *((char *)src + i); } else { char *p = dest + count; const char *s = src + count; -- 1.6.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |