linux-kernel - Re: [PATCH] binfmt_misc.c: avoid potential kernel stack overflow

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20080818162046.f6c41e84.akpm@linux-foundation.org>
Date:	Mon, 18 Aug 2008 16:20:46 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Pavel Emelyanov <xemul@...nvz.org>
Cc:	kirill@...temov.name, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] binfmt_misc.c: avoid potential kernel stack overflow

On Mon, 18 Aug 2008 18:09:23 +0400
Pavel Emelyanov <xemul@...nvz.org> wrote:

> (Put lkml in Cc. The original message is beyond)
> 
> Oops! My fault. The problem is that in case of modularized binfmt,
> the appropriate binary handler gets registered _before_ the script
> one and sets the misc_bang flag even too early.
> 
> Thus when we launch a script the load_misc_binary sets this bang,
> then returns error, since the binary is actually a script, then the
> load_script_binary successfully loads the script, then it loads the
> misc binary again, which exits with the -ENOEXEC error due to bang 
> set.
> 
> This patch helped my box, what about yours?
> 
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index 7562053..8d7e88e 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -120,8 +120,6 @@ static int load_misc_binary(struct linux_binprm *bprm, struct pt_regs *regs)
>  	if (bprm->misc_bang)
>  		goto _ret;
>  
> -	bprm->misc_bang = 1;
> -
>  	/* to keep locking time low, we copy the interpreter string */
>  	read_lock(&entries_lock);
>  	fmt = check_file(bprm);
> @@ -199,6 +197,8 @@ static int load_misc_binary(struct linux_binprm *bprm, struct pt_regs *regs)
>  	if (retval < 0)
>  		goto _error;
>  
> +	bprm->misc_bang = 1;
> +
>  	retval = search_binary_handler (bprm, regs);
>  	if (retval < 0)
>  		goto _error;

<scrabble, hunt>

I put together the below description.  It has no signed-off-by: (yet).
Has this been sufficiently well tested and checked to be in a merge-ready
state?

Thanks.



From: Pavel Emelyanov <xemul@...nvz.org>

Fix a regression introduced by 3a2e7f47d71e1df86acc1dda6826890b6546a4e1
("binfmt_misc.c: avoid potential kernel stack overflow").

In the case of modularized binfmt, the appropriate binary handler gets
registered _before_ the script one and sets the misc_bang flag even too
early.

Thus when we launch a script the load_misc_binary sets this bang, then
returns error, since the binary is actually a script, then the
load_script_binary successfully loads the script, then it loads the misc
binary again, which exits with the -ENOEXEC error due to bang set.

Reported-and-tested-by: Kirill A. Shutemov <kirill@...temov.name>
Cc: <stable@...nel.org>		[2.6.26.x]
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 fs/binfmt_misc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN fs/binfmt_misc.c~binfmt_miscc-avoid-potential-kernel-stack-overflow fs/binfmt_misc.c
--- a/fs/binfmt_misc.c~binfmt_miscc-avoid-potential-kernel-stack-overflow
+++ a/fs/binfmt_misc.c
@@ -120,8 +120,6 @@ static int load_misc_binary(struct linux
 	if (bprm->misc_bang)
 		goto _ret;
 
-	bprm->misc_bang = 1;
-
 	/* to keep locking time low, we copy the interpreter string */
 	read_lock(&entries_lock);
 	fmt = check_file(bprm);
@@ -199,6 +197,8 @@ static int load_misc_binary(struct linux
 	if (retval < 0)
 		goto _error;
 
+	bprm->misc_bang = 1;
+
 	retval = search_binary_handler (bprm, regs);
 	if (retval < 0)
 		goto _error;
_

--
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/