linux-kernel - Re: + fs-binfmts-better-handling-of-binfmt-loops.patch added to -mm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130801163237.GA16070@redhat.com>
Date:	Thu, 1 Aug 2013 18:32:37 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Zach Levis <zml@...ux.vnet.ibm.com>
Cc:	Zach Levis <zach@...hsthings.com>, Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: + fs-binfmts-better-handling-of-binfmt-loops.patch added to
	-mm tree

On 08/01, Zach Levis wrote:
>
> So an example of what this would be used for (going into commit message 
> of a v2 with your earlier suggestions):

Ah, so you are going to send v2, great.

May I ask you to wait a little bit? Once again, I believe that
search_binary_handler() needs a cleanup + minor fix. I'll try
to send the patch today.

> With this patch, an error is printed

I agree, it makes sense to print an error with names.

> and search_binary_handler()
> continues on to the next handler, allowing the original executable to
> run normally so the user can (hopefully) fix their misconfiguration more
> easily.

Still not sure this makes sense, but I can't judge and I won't argue.

>>> And I do not think we should ignore the possible error from
>>> copy_strings(). Even if we know that it succeeded before, another
>>> thread can, say, unmap this memory in between.
>>
>> And since we do copy_strings() again we probably need acct_arg_size()
>> after remove_arg_zero() loop, although this is not that important.
> I'm not sure if that's even necessary.

Yes, I was wrong, thanks for correcting me. We don't need this.

> It looks like there's
> copy_strings()->get_arg_page()->acct_arg_size() that's already called.

This doesn't matter, this won't unaccount the memory. But I was
wrong anyway, we do not need to unaccount because vma won't grow.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/