Messages in this thread | | | From | Bryan Donlan <> | Date | Sat, 10 Oct 2009 03:11:48 -0400 | Subject | Re: [resend][PATCH] Added PR_SET_PROCTITLE_AREA option for prctl() |
| |
On Sat, Oct 10, 2009 at 2:32 AM, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>> It does seem like a maximum spin count should be put in there - and >> maybe a timeout as well (since with FUSE etc it's possible to engineer >> page faults that take arbitrarily long). >> Also, it occurs to me that: > > makes sense. > I like maximum spin rather than timeout.
I'm worried about the scenario where process A sets its cmdline buffer to point to a page which will take a _VERY_ long time to pagein (maybe forever), and then process B goes to try to read its cmdline. What happens now? Process A can arrange for this to happen by using a FUSE filesystem that sits on a read forever. And since the first thing the admin's likely to do to track down the problem is 'ps awux', this is liable to be a rather nasty DoS...
Of course, this is no worse than it is now - it's already possible to replace the page in question. But we should think about ways this could be fixed for good...
> >>> + do { >>> + seq = read_seqbegin(&mm->arg_lock); >>> + >>> + len = mm->arg_end - mm->arg_start; >>> + if (len > PAGE_SIZE) >>> + len = PAGE_SIZE; >> >> If arg_end or arg_start are modified after this, is it truly safe to >> assume that len will remain <= PAGE_SIZE without a memory barrier >> before the conditional? > > 1) access_process_vm() doesn't return error value. > 2) read_seqretry(&mm->arg_lock, seq)) check seq, not mm->arg_start or len. > > then, if arg_{start,end} is modified, access_process_vm() may return 0 > and strnlen > makes bad calculation, but read_seqretry() can detect its modify > rightly. I think.
No, I'm worried about what if the compiler decides to rewrite like so: if (mm->arg_end - mm->arg_start > PAGE_SIZE) len = PAGE_SIZE; else /* here we reload arg_end/arg_start! */ len = mm->arg_end - mm->arg_start;
Now we might write into buffer more than PAGE_SIZE bytes, which is probably a buffer overrun into kernel space... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |