Messages in this thread Patch in this message | | | Date | Fri, 18 Sep 2009 21:26:26 +0200 | From | Ian Schram <> | Subject | perf_copy_attr pointer arithmetic weirdness |
| |
There is some -to me at least- weird code in per_copy_attr. Which supposedly checks that all bytes trailing a struct are zero.
It doesn't seem to get pointer arithmetic right. Since it increments an iterating pointer by sizeof(unsigned long) rather than 1.
I believe this has an impact on the exploitability of the recent buffer overflow in the perf_copy_attr function. I'm pretty sure I'm not the only one who noticed this, but i couldn't find it being mentioned. For some reason people prefer mmaping something at zero these days?
I have appended a patch locating the issue. The PTR_ALIGN stuff right above it doesn't seem to take any boundary conditions into account which is probably not a good thing either.
(I'm not subscribed, please add me in CC.)
signed-of-by Ian Schram <ischram@telenet.be> diff --git a/kernel/perf_counter.c b/kernel/perf_counter.c index 8cb94a5..9c7590e 100644 --- a/kernel/perf_counter.c +++ b/kernel/perf_counter.c @@ -4208,7 +4208,7 @@ static int perf_copy_attr(struct perf_counter_attr __user *uattr, end = PTR_ALIGN((void __user *)uattr + size, sizeof(unsigned long));
- for (; addr < end; addr += sizeof(unsigned long)) { + for (; addr < end; ++addr) { ret = get_user(val, addr); if (ret) return ret;
| |