[PATCH -mm 1/1] ptrace: PTRACE_GETFDPIC: fix the unsafe usage of child->mm
in [Kernel]
|
Prev: linux-next: build failure after merge of the final tree (acpi tree related)
Next: NFS, race in writeback?
From: Mike Frysinger on 24 May 2010 00:40 On Sat, May 22, 2010 at 12:54, Oleg Nesterov wrote: > Now that Mike Frysinger unified the FDPIC ptrace code, we can fix > the unsafe usage of child->mm in ptrace_request(PTRACE_GETFDPIC). > > We have the reference to task_struct, and ptrace_check_attach() > verified the tracee is stopped. But nothing can protect from > SIGKILL after that, we must not assume child->mm != NULL. gdb still works with FDPIC apps after this, so presumably it works fine :). ive added it to the Blackfin tree to get more testing on our side (not that i'll be pushing it out or anything). thanks! -mike -- 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/
From: Mike Frysinger on 24 May 2010 21:40 On Mon, May 24, 2010 at 19:42, Roland McGrath wrote: >> You mean, pass it to arch_ptrace() ? >> >> grep, grep, grep. I guess I understand you. We have more unsafe code >> like this in arch/*/kernel/ptrace.c. Of course, it can be fixed without >> doing get_task_mm() in sys_ptrace(), but perhaps it would be more clean >> to do what you suggest. >> >> Roland, what do you think? > > The mm pointer is only used by these uncommon ptrace operations that exist > only in certain unusual arch's (and they're all ill-advised old arch ptrace > ABI additions, at that). are you suggesting the FDPIC additions are ill-advised as well ? curious how you would have implemented this if that's the case ... -mike -- 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/
From: Roland McGrath on 25 May 2010 15:20
> are you suggesting the FDPIC additions are ill-advised as well ? > curious how you would have implemented this if that's the case ... They are certainly not as dismal as the arch PTRACE_PEEKUSR delivering mm->fields. But, frankly I don't think ptrace is the right mechanism for delivering any read-only, process-shared information. You can use some /proc/pid/foo for that. (The "dismal" cases deliver things like start_code, which is already available in /proc/pid/stat.) Thanks, Roland -- 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/ |