perf_copy_attr pointer arithmetic weirdness

[Ian Schram]

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@xxxxxxxxxx>
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;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/