All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Paul Burton <paul.burton@imgtec.com>, Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/10] binfmt_elf: load interpreter program headers earlier
Date: Thu, 13 Nov 2014 13:20:20 +0100	[thread overview]
Message-ID: <20141113122011.GE23422@ulmo> (raw)
In-Reply-To: <1410420623-11691-3-git-send-email-paul.burton@imgtec.com>


[-- Attachment #1.1: Type: text/plain, Size: 2976 bytes --]

On Thu, Sep 11, 2014 at 08:30:15AM +0100, Paul Burton wrote:
> Load the program headers of an ELF interpreter early enough in
> load_elf_binary that they can be examined before it's too late to return
> an error from an exec syscall. This patch does not perform any such
> checking, it merely lays the groundwork for a further patch to do so.
> 
> No functional change is intended.
> 
> Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> ---
>  fs/binfmt_elf.c | 36 ++++++++++++++++++------------------
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
[...]

kmemleak started complaining for me recently and the stacktrace (see
below) points to this function:

	unreferenced object 0xec0f77c0 (size 192):
	  comm "kworker/u8:0", pid 169, jiffies 4294939367 (age 86.360s)
	  hex dump (first 32 bytes):
	    01 00 00 70 1c ef 01 00 1c ef 01 00 1c ef 01 00  ...p............
	    a0 00 00 00 a0 00 00 00 04 00 00 00 04 00 00 00  ................
	  backtrace:
	    [<c00ec080>] __kmalloc+0x104/0x190
	    [<c01387d4>] load_elf_phdrs+0x60/0x8c
	    [<c0138cb4>] load_elf_binary+0x280/0x12d8
	    [<c00f8ef0>] search_binary_handler+0x80/0x1f0
	    [<c00fa370>] do_execveat_common+0x570/0x658
	    [<c00fa480>] do_execve+0x28/0x30
	    [<c0038eb4>] ____call_usermodehelper+0x144/0x19c
	    [<c000e638>] ret_from_fork+0x14/0x3c
	    [<ffffffff>] 0xffffffff

> @@ -605,7 +598,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  	int load_addr_set = 0;
>  	char * elf_interpreter = NULL;
>  	unsigned long error;
> -	struct elf_phdr *elf_ppnt, *elf_phdata;
> +	struct elf_phdr *elf_ppnt, *elf_phdata, *interp_elf_phdata = NULL;
>  	unsigned long elf_bss, elf_brk;
>  	int retval, i;
>  	unsigned long elf_entry;
> @@ -729,6 +722,12 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  		/* Verify the interpreter has a valid arch */
>  		if (!elf_check_arch(&loc->interp_elf_ex))
>  			goto out_free_dentry;
> +
> +		/* Load the interpreter program headers */
> +		interp_elf_phdata = load_elf_phdrs(&loc->interp_elf_ex,
> +						   interpreter);
> +		if (!interp_elf_phdata)
> +			goto out_free_dentry;
>  	}
>  
>  	/* Flush all traces of the currently running executable */
> @@ -912,7 +911,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  		elf_entry = load_elf_interp(&loc->interp_elf_ex,
>  					    interpreter,
>  					    &interp_map_addr,
> -					    load_bias);
> +					    load_bias, interp_elf_phdata);
>  		if (!IS_ERR((void *)elf_entry)) {
>  			/*
>  			 * load_elf_interp() returns relocation
> @@ -1009,6 +1008,7 @@ out_ret:
>  
>  	/* error cleanup */
>  out_free_dentry:
> +	kfree(interp_elf_phdata);

I think what happens is that the interp_elf_phdata memory is freed only
in the error cleanup path, but not when the function actually succeeds.

The attached patch plugs the leak for me.

Thierry

[-- Attachment #1.2: patch --]
[-- Type: text/plain, Size: 308 bytes --]

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index f95da60e440e..8a9be83e88c2 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1029,6 +1029,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 		}
 	}
 
+	kfree(interp_elf_phdata);
 	kfree(elf_phdata);
 
 	set_binfmt(&elf_format);

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-11-13 12:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11  7:30 [PATCH 00/10] MIPS O32 new FP ABI support Paul Burton
2014-09-11  7:30 ` Paul Burton
2014-09-11  7:30 ` [PATCH 01/10] binfmt_elf: hoist ELF program header loading to a function Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-09-11  7:30 ` [PATCH 02/10] binfmt_elf: load interpreter program headers earlier Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-11-13 12:20   ` Thierry Reding [this message]
2014-11-13 17:29     ` Ralf Baechle
2014-09-11  7:30 ` [PATCH 03/10] binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-11-12 13:41   ` Thierry Reding
2014-11-13  0:16     ` Ralf Baechle
2014-11-13 12:25       ` Thierry Reding
2014-09-11  7:30 ` [PATCH 04/10] MIPS: define bits introduced for hybrid FPRs Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-09-11  7:30 ` [PATCH 05/10] MIPS: detect presence of the FRE & UFR bits Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-09-11  7:30 ` [PATCH 06/10] MIPS: ensure Config5.UFE is clear on boot Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-09-11  7:30 ` [PATCH 07/10] MIPS: support for hybrid FPRs Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-12-23 23:21   ` Aaro Koskinen
2014-12-23 23:31     ` James Hogan
2014-12-23 23:31       ` James Hogan
2014-12-23 23:51       ` Aaro Koskinen
2014-09-11  7:30 ` [PATCH 08/10] MIPS: ELF: add definition for the .MIPS.abiflags section Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-09-11  7:30 ` [PATCH 09/10] MIPS: ELF: set FP mode according to .MIPS.abiflags Paul Burton
2014-09-11  7:30   ` Paul Burton
2014-09-11  7:30 ` [PATCH 10/10] MIPS: Kconfig option to better exercise/debug hybrid FPRs Paul Burton
2014-09-11  7:30   ` Paul Burton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141113122011.GE23422@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=paul.burton@imgtec.com \
    --cc=ralf@linux-mips.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.