LKML Archive on lore.kernel.org
 help / Atom feed
* [PATCH 0/2] binfmt_elf: fix calculations for bss padding
@ 2016-07-08 21:48 Kees Cook
  2016-07-08 21:48 ` [PATCH 1/2] " Kees Cook
  2016-07-08 21:48 ` [PATCH 2/2] mm: refuse wrapped vm_brk requests Kees Cook
  0 siblings, 2 replies; 9+ messages in thread
From: Kees Cook @ 2016-07-08 21:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Oleg Nesterov, Chen Gang,
	Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
	Andrey Ryabinin, linux-fsdevel, linux-mm, linux-kernel

This fixes a double-bug in ELF loading, as noticed by Hector
Marco-Gisbert. To quote his original email:


 The size of the bss section for some interpreters is not correctly
 calculated resulting in unnecessary calls to vm_brk() with enormous size
 values.

 The bug appears when loading some interpreters with a small bss size. Once
 the last loadable segment has been loaded, the bss section is zeroed up to
 the page boundary and the elf_bss variable is updated to this new page
 boundary.  Because of this update (alignment), the last_bss could be less
 than elf_bss and the subtraction "last_bss - elf_bss" value could overflow.
 ...
 [e.g.] The size value requested to the vm_brk() call (last_bss - elf_bss) is
 0xfffffffffffff938 and internally this size is page aligned in the do_brk()
 function resulting in a 0 length request.


This series takes a slightly different approach to fixing it and updates
vm_brk to refuse bad allocation sizes.

-Kees

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 1/2] binfmt_elf: fix calculations for bss padding
  2016-07-08 21:48 [PATCH 0/2] binfmt_elf: fix calculations for bss padding Kees Cook
@ 2016-07-08 21:48 ` " Kees Cook
  2016-07-12 22:32   ` Kees Cook
  2016-07-08 21:48 ` [PATCH 2/2] mm: refuse wrapped vm_brk requests Kees Cook
  1 sibling, 1 reply; 9+ messages in thread
From: Kees Cook @ 2016-07-08 21:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Oleg Nesterov, Chen Gang,
	Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
	Andrey Ryabinin, linux-fsdevel, linux-mm, linux-kernel

A double-bug exists in the bss calculation code, where an overflow can
happen in the "last_bss - elf_bss" calculation, but vm_brk internally
aligns the argument, underflowing it, wrapping back around safe. We
shouldn't depend on these bugs staying in sync, so this cleans up the bss
padding handling to avoid the overflow.

This moves the bss padzero() before the last_bss > elf_bss case, since
the zero-filling of the ELF_PAGE should have nothing to do with the
relationship of last_bss and elf_bss: any trailing portion should be
zeroed, and a zero size is already handled by padzero().

Then it handles the math on elf_bss vs last_bss correctly. These need
to both be ELF_PAGE aligned to get the comparison correct, since that's
the expected granularity of the mappings. Since elf_bss already had
alignment-based padding happen in padzero(), the "start" of the new
vm_brk() should be moved forward as done in the original code. However,
since the "end" of the vm_brk() area will already become PAGE_ALIGNed in
vm_brk() then last_bss should get aligned here to avoid hiding it as a
side-effect.

Additionally makes a cosmetic change to the initial last_bss calculation
so it's easier to read in comparison to the load_addr calculation above it
(i.e. the only difference is p_filesz vs p_memsz).

Reported-by: Hector Marco-Gisbert <hecmargi@upv.es>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 fs/binfmt_elf.c | 34 ++++++++++++++++++----------------
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index e158b22ef32f..fe948933bcc5 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -605,28 +605,30 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex,
 			 * Do the same thing for the memory mapping - between
 			 * elf_bss and last_bss is the bss section.
 			 */
-			k = load_addr + eppnt->p_memsz + eppnt->p_vaddr;
+			k = load_addr + eppnt->p_vaddr + eppnt->p_memsz;
 			if (k > last_bss)
 				last_bss = k;
 		}
 	}
 
+	/*
+	 * Now fill out the bss section: first pad the last page from
+	 * the file up to the page boundary, and zero it from elf_bss
+	 * up to the end of the page.
+	 */
+	if (padzero(elf_bss)) {
+		error = -EFAULT;
+		goto out;
+	}
+	/*
+	 * Next, align both the file and mem bss up to the page size,
+	 * since this is where elf_bss was just zeroed up to, and where
+	 * last_bss will end after the vm_brk() below.
+	 */
+	elf_bss = ELF_PAGEALIGN(elf_bss);
+	last_bss = ELF_PAGEALIGN(last_bss);
+	/* Finally, if there is still more bss to allocate, do it. */
 	if (last_bss > elf_bss) {
-		/*
-		 * Now fill out the bss section.  First pad the last page up
-		 * to the page boundary, and then perform a mmap to make sure
-		 * that there are zero-mapped pages up to and including the
-		 * last bss page.
-		 */
-		if (padzero(elf_bss)) {
-			error = -EFAULT;
-			goto out;
-		}
-
-		/* What we have mapped so far */
-		elf_bss = ELF_PAGESTART(elf_bss + ELF_MIN_ALIGN - 1);
-
-		/* Map the last of the bss segment */
 		error = vm_brk(elf_bss, last_bss - elf_bss);
 		if (error)
 			goto out;
-- 
2.7.4

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 2/2] mm: refuse wrapped vm_brk requests
  2016-07-08 21:48 [PATCH 0/2] binfmt_elf: fix calculations for bss padding Kees Cook
  2016-07-08 21:48 ` [PATCH 1/2] " Kees Cook
@ 2016-07-08 21:48 ` Kees Cook
  2016-07-11 12:28   ` Oleg Nesterov
  1 sibling, 1 reply; 9+ messages in thread
From: Kees Cook @ 2016-07-08 21:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Oleg Nesterov, Chen Gang,
	Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
	Andrey Ryabinin, linux-fsdevel, linux-mm, linux-kernel

The vm_brk() alignment calculations should refuse to overflow. The ELF
loader depending on this, but it has been fixed now. No other unsafe
callers have been found.

Reported-by: Hector Marco-Gisbert <hecmargi@upv.es>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 mm/mmap.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index de2c1769cc68..1874ee0e1266 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2625,16 +2625,18 @@ static inline void verify_mm_writelocked(struct mm_struct *mm)
  *  anonymous maps.  eventually we may be able to do some
  *  brk-specific accounting here.
  */
-static int do_brk(unsigned long addr, unsigned long len)
+static int do_brk(unsigned long addr, unsigned long request)
 {
 	struct mm_struct *mm = current->mm;
 	struct vm_area_struct *vma, *prev;
-	unsigned long flags;
+	unsigned long flags, len;
 	struct rb_node **rb_link, *rb_parent;
 	pgoff_t pgoff = addr >> PAGE_SHIFT;
 	int error;
 
-	len = PAGE_ALIGN(len);
+	len = PAGE_ALIGN(request);
+	if (len < request)
+		return -ENOMEM;
 	if (!len)
 		return 0;
 
-- 
2.7.4

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] mm: refuse wrapped vm_brk requests
  2016-07-08 21:48 ` [PATCH 2/2] mm: refuse wrapped vm_brk requests Kees Cook
@ 2016-07-11 12:28   ` Oleg Nesterov
  2016-07-11 18:01     ` Kees Cook
  0 siblings, 1 reply; 9+ messages in thread
From: Oleg Nesterov @ 2016-07-11 12:28 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Chen Gang, Michal Hocko,
	Konstantin Khlebnikov, Andrea Arcangeli, Andrey Ryabinin,
	linux-fsdevel, linux-mm, linux-kernel

I think both patches are fine, just a question.

On 07/08, Kees Cook wrote:
>
> -static int do_brk(unsigned long addr, unsigned long len)
> +static int do_brk(unsigned long addr, unsigned long request)
>  {
>  	struct mm_struct *mm = current->mm;
>  	struct vm_area_struct *vma, *prev;
> -	unsigned long flags;
> +	unsigned long flags, len;
>  	struct rb_node **rb_link, *rb_parent;
>  	pgoff_t pgoff = addr >> PAGE_SHIFT;
>  	int error;
>  
> -	len = PAGE_ALIGN(len);
> +	len = PAGE_ALIGN(request);
> +	if (len < request)
> +		return -ENOMEM;

So iiuc "len < request" is only possible if len == 0, right?

>  	if (!len)
>  		return 0;

and thus this patch fixes the error code returned by do_brk() in case
of overflow, now it returns -ENOMEM rather than zero. Perhaps

	if (!len)
		return 0;
	len = PAGE_ALIGN(len);
	if (!len)
		return -ENOMEM;

would be more clear but this is subjective.

I am wondering if we should shift this overflow check to the caller(s).
Say, sys_brk() does find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE)
before do_brk(), and in case of overflow find_vma_intersection() can
wrongly return NULL.

Then do_brk() will be called with len = -oldbrk, this can overflow or
not but in any case this doesn't look right too.

Or I am totally confused?

Oleg.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] mm: refuse wrapped vm_brk requests
  2016-07-11 12:28   ` Oleg Nesterov
@ 2016-07-11 18:01     ` Kees Cook
  2016-07-12 13:39       ` Oleg Nesterov
  0 siblings, 1 reply; 9+ messages in thread
From: Kees Cook @ 2016-07-11 18:01 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andrew Morton, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Chen Gang, Michal Hocko,
	Konstantin Khlebnikov, Andrea Arcangeli, Andrey Ryabinin,
	linux-fsdevel, Linux-MM, LKML

On Mon, Jul 11, 2016 at 8:28 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> I think both patches are fine, just a question.
>
> On 07/08, Kees Cook wrote:
>>
>> -static int do_brk(unsigned long addr, unsigned long len)
>> +static int do_brk(unsigned long addr, unsigned long request)
>>  {
>>       struct mm_struct *mm = current->mm;
>>       struct vm_area_struct *vma, *prev;
>> -     unsigned long flags;
>> +     unsigned long flags, len;
>>       struct rb_node **rb_link, *rb_parent;
>>       pgoff_t pgoff = addr >> PAGE_SHIFT;
>>       int error;
>>
>> -     len = PAGE_ALIGN(len);
>> +     len = PAGE_ALIGN(request);
>> +     if (len < request)
>> +             return -ENOMEM;
>
> So iiuc "len < request" is only possible if len == 0, right?

Oh, hrm, good point.

>
>>       if (!len)
>>               return 0;
>
> and thus this patch fixes the error code returned by do_brk() in case
> of overflow, now it returns -ENOMEM rather than zero. Perhaps
>
>         if (!len)
>                 return 0;
>         len = PAGE_ALIGN(len);
>         if (!len)
>                 return -ENOMEM;
>
> would be more clear but this is subjective.

I'm fine either way.

> I am wondering if we should shift this overflow check to the caller(s).
> Say, sys_brk() does find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE)
> before do_brk(), and in case of overflow find_vma_intersection() can
> wrongly return NULL.
>
> Then do_brk() will be called with len = -oldbrk, this can overflow or
> not but in any case this doesn't look right too.
>
> Or I am totally confused?

I think the callers shouldn't request a negative value, sure, but
vm_brk should notice and refuse it.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] mm: refuse wrapped vm_brk requests
  2016-07-11 18:01     ` Kees Cook
@ 2016-07-12 13:39       ` Oleg Nesterov
  2016-07-12 17:15         ` Kees Cook
  0 siblings, 1 reply; 9+ messages in thread
From: Oleg Nesterov @ 2016-07-12 13:39 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Chen Gang, Michal Hocko,
	Konstantin Khlebnikov, Andrea Arcangeli, Andrey Ryabinin,
	linux-fsdevel, Linux-MM, LKML

On 07/11, Kees Cook wrote:
>
> On Mon, Jul 11, 2016 at 8:28 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > and thus this patch fixes the error code returned by do_brk() in case
> > of overflow, now it returns -ENOMEM rather than zero. Perhaps
> >
> >         if (!len)
> >                 return 0;
> >         len = PAGE_ALIGN(len);
> >         if (!len)
> >                 return -ENOMEM;
> >
> > would be more clear but this is subjective.
>
> I'm fine either way.

Me too, so feel free to ignore,

> > I am wondering if we should shift this overflow check to the caller(s).
> > Say, sys_brk() does find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE)
> > before do_brk(), and in case of overflow find_vma_intersection() can
> > wrongly return NULL.
> >
> > Then do_brk() will be called with len = -oldbrk, this can overflow or
> > not but in any case this doesn't look right too.
> >
> > Or I am totally confused?
>
> I think the callers shouldn't request a negative value, sure, but
> vm_brk should notice and refuse it.

Not sure I understand...

I tried to say that, with or without this change, sys_brk() should check
for overflow too, otherwise it looks buggy.

Oleg.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] mm: refuse wrapped vm_brk requests
  2016-07-12 13:39       ` Oleg Nesterov
@ 2016-07-12 17:15         ` Kees Cook
  2016-07-13 17:00           ` Oleg Nesterov
  0 siblings, 1 reply; 9+ messages in thread
From: Kees Cook @ 2016-07-12 17:15 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andrew Morton, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Chen Gang, Michal Hocko,
	Konstantin Khlebnikov, Andrea Arcangeli, Andrey Ryabinin,
	linux-fsdevel, Linux-MM, LKML

On Tue, Jul 12, 2016 at 9:39 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 07/11, Kees Cook wrote:
>>
>> On Mon, Jul 11, 2016 at 8:28 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>> >
>> > and thus this patch fixes the error code returned by do_brk() in case
>> > of overflow, now it returns -ENOMEM rather than zero. Perhaps
>> >
>> >         if (!len)
>> >                 return 0;
>> >         len = PAGE_ALIGN(len);
>> >         if (!len)
>> >                 return -ENOMEM;
>> >
>> > would be more clear but this is subjective.
>>
>> I'm fine either way.
>
> Me too, so feel free to ignore,
>
>> > I am wondering if we should shift this overflow check to the caller(s).
>> > Say, sys_brk() does find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE)
>> > before do_brk(), and in case of overflow find_vma_intersection() can
>> > wrongly return NULL.
>> >
>> > Then do_brk() will be called with len = -oldbrk, this can overflow or
>> > not but in any case this doesn't look right too.
>> >
>> > Or I am totally confused?
>>
>> I think the callers shouldn't request a negative value, sure, but
>> vm_brk should notice and refuse it.
>
> Not sure I understand...
>
> I tried to say that, with or without this change, sys_brk() should check
> for overflow too, otherwise it looks buggy.

Hmm, it's not clear to me the right way to fix sys_brk(), but it looks
like my change to do_brk() would catch the problem?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] binfmt_elf: fix calculations for bss padding
  2016-07-08 21:48 ` [PATCH 1/2] " Kees Cook
@ 2016-07-12 22:32   ` Kees Cook
  0 siblings, 0 replies; 9+ messages in thread
From: Kees Cook @ 2016-07-12 22:32 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Oleg Nesterov, Chen Gang,
	Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
	Andrey Ryabinin, linux-fsdevel, Linux-MM, LKML

On Fri, Jul 8, 2016 at 5:48 PM, Kees Cook <keescook@chromium.org> wrote:
> A double-bug exists in the bss calculation code, where an overflow can
> happen in the "last_bss - elf_bss" calculation, but vm_brk internally
> aligns the argument, underflowing it, wrapping back around safe. We
> shouldn't depend on these bugs staying in sync, so this cleans up the bss
> padding handling to avoid the overflow.
>
> This moves the bss padzero() before the last_bss > elf_bss case, since
> the zero-filling of the ELF_PAGE should have nothing to do with the
> relationship of last_bss and elf_bss: any trailing portion should be
> zeroed, and a zero size is already handled by padzero().
>
> Then it handles the math on elf_bss vs last_bss correctly. These need
> to both be ELF_PAGE aligned to get the comparison correct, since that's
> the expected granularity of the mappings. Since elf_bss already had
> alignment-based padding happen in padzero(), the "start" of the new
> vm_brk() should be moved forward as done in the original code. However,
> since the "end" of the vm_brk() area will already become PAGE_ALIGNed in
> vm_brk() then last_bss should get aligned here to avoid hiding it as a
> side-effect.
>
> Additionally makes a cosmetic change to the initial last_bss calculation
> so it's easier to read in comparison to the load_addr calculation above it
> (i.e. the only difference is p_filesz vs p_memsz).
>
> Reported-by: Hector Marco-Gisbert <hecmargi@upv.es>
> Signed-off-by: Kees Cook <keescook@chromium.org>

Andrew or Al, can you pick this up for -next? It doesn't depend on the
do_brk() fix (patch 2/2)...

-Kees

> ---
>  fs/binfmt_elf.c | 34 ++++++++++++++++++----------------
>  1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index e158b22ef32f..fe948933bcc5 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -605,28 +605,30 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex,
>                          * Do the same thing for the memory mapping - between
>                          * elf_bss and last_bss is the bss section.
>                          */
> -                       k = load_addr + eppnt->p_memsz + eppnt->p_vaddr;
> +                       k = load_addr + eppnt->p_vaddr + eppnt->p_memsz;
>                         if (k > last_bss)
>                                 last_bss = k;
>                 }
>         }
>
> +       /*
> +        * Now fill out the bss section: first pad the last page from
> +        * the file up to the page boundary, and zero it from elf_bss
> +        * up to the end of the page.
> +        */
> +       if (padzero(elf_bss)) {
> +               error = -EFAULT;
> +               goto out;
> +       }
> +       /*
> +        * Next, align both the file and mem bss up to the page size,
> +        * since this is where elf_bss was just zeroed up to, and where
> +        * last_bss will end after the vm_brk() below.
> +        */
> +       elf_bss = ELF_PAGEALIGN(elf_bss);
> +       last_bss = ELF_PAGEALIGN(last_bss);
> +       /* Finally, if there is still more bss to allocate, do it. */
>         if (last_bss > elf_bss) {
> -               /*
> -                * Now fill out the bss section.  First pad the last page up
> -                * to the page boundary, and then perform a mmap to make sure
> -                * that there are zero-mapped pages up to and including the
> -                * last bss page.
> -                */
> -               if (padzero(elf_bss)) {
> -                       error = -EFAULT;
> -                       goto out;
> -               }
> -
> -               /* What we have mapped so far */
> -               elf_bss = ELF_PAGESTART(elf_bss + ELF_MIN_ALIGN - 1);
> -
> -               /* Map the last of the bss segment */
>                 error = vm_brk(elf_bss, last_bss - elf_bss);
>                 if (error)
>                         goto out;
> --
> 2.7.4
>



-- 
Kees Cook
Chrome OS & Brillo Security

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] mm: refuse wrapped vm_brk requests
  2016-07-12 17:15         ` Kees Cook
@ 2016-07-13 17:00           ` Oleg Nesterov
  0 siblings, 0 replies; 9+ messages in thread
From: Oleg Nesterov @ 2016-07-13 17:00 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Hector Marco-Gisbert, Ismael Ripoll Ripoll,
	Alexander Viro, Kirill A. Shutemov, Chen Gang, Michal Hocko,
	Konstantin Khlebnikov, Andrea Arcangeli, Andrey Ryabinin,
	linux-fsdevel, Linux-MM, LKML

On 07/12, Kees Cook wrote:
>
> On Tue, Jul 12, 2016 at 9:39 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > I tried to say that, with or without this change, sys_brk() should check
> > for overflow too, otherwise it looks buggy.
>
> Hmm, it's not clear to me the right way to fix sys_brk(), but it looks
> like my change to do_brk() would catch the problem?

How?

Once again, afaics nothing bad can happen, sys_brk() will silently fail,
just the code looks wrong anyway.

Suppose that newbrk == 0 due to overflow, then both

	if (find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE))
		goto out;

and
	if (do_brk(oldbrk, newbrk-oldbrk) < 0)
		goto out;

look buggy.

find_vma_intersection(start_addr, end_addr) expects that start_addr < end_addr.
Again, we do not really care if it returns NULL or not, and newbrk == 0 just
means it will certainly return NULL if there is something above oldbrk. Just
looks buggy/confusing.

do_brk(0 - oldbrk) will fail and this is what we want. But not because
your change will catch the problem, PAGE_ALIGNE(-oldbrk) won't necessarily
overflow. However, -oldbrk > TASK_SIZE so get_unmapped_area() should fail.

Nevermind, this is almost off-topic, so let me repeat just in case that
both patches look good to me.

Oleg.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-08 21:48 [PATCH 0/2] binfmt_elf: fix calculations for bss padding Kees Cook
2016-07-08 21:48 ` [PATCH 1/2] " Kees Cook
2016-07-12 22:32   ` Kees Cook
2016-07-08 21:48 ` [PATCH 2/2] mm: refuse wrapped vm_brk requests Kees Cook
2016-07-11 12:28   ` Oleg Nesterov
2016-07-11 18:01     ` Kees Cook
2016-07-12 13:39       ` Oleg Nesterov
2016-07-12 17:15         ` Kees Cook
2016-07-13 17:00           ` Oleg Nesterov

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox