On 17/09/11 02:36, halfdog wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ryan Mallon wrote: > >>> ... >> That's fine. I originally went looking after a discussion with >> Mark about the weird strnlen_user semantics and this usage looked >> incorrect to me because it wasn't obviously checking >= >> MAX_ARG_STRLEN. >> >> The rework I think makes it a bit more clear and passes the correct >> max length to strnlen_user. Its a bit odd to pass MAX_ARG_STRLEN >> and then check if it is longer than bprm->len, and I guess assumes >> that bprm->len is less than MAX_ARG_STRLEN. >> >> Feel free to drop the patch if you think it is just churn. > As you are already busy with fs/exec.c and strnlen_user, could you > please check, if the timerace (argv/envp corruption) using > strnlen_user could also be fixed within the same patch (if bug still > in kernel). See > > https://bugzilla.kernel.org/show_bug.cgi?id=39222 With kernel.org currently being down I cannot see that bug report unfortunately, so I don't know what the bug you are referring to is. > The race occurs when one thread issues exec while another one with > shared memory pages is flipping char/0-bytes of the args or envptrs, > causing random split (number greater maxargs - no problem, silently > droped)/fusion (greater MAX_ARG_STRLEN - might harm dumb programs) or > removal of all args including program name on top of new stack when > calling via binfmt handlers (might have influenced old ldlinux/libc > pre 2009?? when handling suid binaries) It doesn't sound like my patch would have fixed that. The only issue that my patch would have corrected is the case where bprm->len is greater than MAX_ARG_STRLEN. MAX_ARG_STRLEN is pretty big though (32 * PAGE_SIZE), so I don't see that being an issue very often. ~Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
