Brainy: User-Triggerable Kernel Memory Leak in execve()

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Brainy: User-Triggerable Kernel Memory Leak in execve()

Maxime Villard-2
Hi,
I put here a bug among others:

------------------------- sys/kern/kern_exec.c -------------------------

        char *pathbuf = NULL;

        [...]

                pathbuf = pool_get(&namei_pool, PR_WAITOK);

        [...]

        /* setup new registers and do misc. setup. */
        if (pack.ep_emul->e_fixup != NULL) {
                if ((*pack.ep_emul->e_fixup)(p, &pack) != 0)
                        goto free_pack_abort;
        }

        [...]

free_pack_abort:
        free(pack.ep_hdr, M_EXEC, 0);
        exit1(p, W_EXITCODE(0, SIGABRT), EXIT_NORMAL);

        /* NOTREACHED */
        atomic_clearbits_int(&pr->ps_flags, PS_INEXEC);
        if (pathbuf != NULL)
                pool_put(&namei_pool, pathbuf);

        return (0);
}

------------------------------------------------------------------------

'pathbuf' is leaked.

This path being obviously reachable from userland, it is easy for a
local (un)privileged user to cause the kernel to run out of memory and
become unresponsive. OpenBSD 5.7 is affected, and quite certainly
previous releases.

Exploit here:

        http://m00nbsd.net/garbage/OpenBSD_execve-DoS.txt

You can see with vmstat -m that the namei pool becomes enormous.

Found by The Brainy Code Scanner.

It is not the last bug Brainy has found, but it is the last one I
report. I don't have time for that.

Maxime

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Ville Valkonen
On Jul 21, 2015 9:32 AM, "Maxime Villard" <[hidden email]> wrote:

>
> Hi,
> I put here a bug among others:
>
> ------------------------- sys/kern/kern_exec.c -------------------------
>
>         char *pathbuf = NULL;
>
>         [...]
>
>                 pathbuf = pool_get(&namei_pool, PR_WAITOK);
>
>         [...]
>
>         /* setup new registers and do misc. setup. */
>         if (pack.ep_emul->e_fixup != NULL) {
>                 if ((*pack.ep_emul->e_fixup)(p, &pack) != 0)
>                         goto free_pack_abort;
>         }
>
>         [...]
>
> free_pack_abort:
>         free(pack.ep_hdr, M_EXEC, 0);
>         exit1(p, W_EXITCODE(0, SIGABRT), EXIT_NORMAL);
>
>         /* NOTREACHED */
>         atomic_clearbits_int(&pr->ps_flags, PS_INEXEC);
>         if (pathbuf != NULL)
>                 pool_put(&namei_pool, pathbuf);
>
>         return (0);
> }
>
> ------------------------------------------------------------------------
>
> 'pathbuf' is leaked.
>
> This path being obviously reachable from userland, it is easy for a
> local (un)privileged user to cause the kernel to run out of memory and
> become unresponsive. OpenBSD 5.7 is affected, and quite certainly
> previous releases.
>
> Exploit here:
>
>         http://m00nbsd.net/garbage/OpenBSD_execve-DoS.txt
>
> You can see with vmstat -m that the namei pool becomes enormous.
>
> Found by The Brainy Code Scanner.
>
> It is not the last bug Brainy has found, but it is the last one I
> report. I don't have time for that.
>
> Maxime

Why such a dramatic tone?

--
Ville
Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Alexey Suslikov
Ville Valkonen <weezelding <at> gmail.com> writes:

> On Jul 21, 2015 9:32 AM, "Maxime Villard" <max <at> m00nbsd.net> wrote:
> > It is not the last bug Brainy has found, but it is the last one I
> > report. I don't have time for that.
> >
> > Maxime
>
> Why such a dramatic tone?

Because that famous "thank you small people" sounds more and more
ridiculous (some says Goebels'ish), no?

sam
Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

sam
In reply to this post by Maxime Villard-2
On Tue, 21 Jul 2015 11:31:44 +0200
Maxime Villard <[hidden email]> wrote:

> Found by The Brainy Code Scanner.
>
> It is not the last bug Brainy has found, but it is the last one I
> report. I don't have time for that.
>

How about you release the Brainy Code Scanner then?

"I have so many bugs; in fact, there are so many, I don't even have the
time to report them! My scanner is so good!"

Or perhaps you should report 'just' the relatively important ones?

> Maxime
>

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Alexey Suslikov
sam <sam <at> cmpct.info> writes:

> How about you release the Brainy Code Scanner then?
>
> "I have so many bugs; in fact, there are so many, I don't even have the
> time to report them! My scanner is so good!"
>
> Or perhaps you should report 'just' the relatively important ones?

Made my day.

Searching for bugs is for brainy. Victims of propaganda don't even
search archives.

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Maxime Villard-2
In reply to this post by sam
Well, I guess I'll have to admit that I find your attitude extremely
disrespectful. But I don't tend to feel particularly offended by this
kind of things, so it probably does not matter.


Le 21/07/2015 12:31, sam a écrit :

> On Tue, 21 Jul 2015 11:31:44 +0200
> Maxime Villard <[hidden email]> wrote:
>
>> Found by The Brainy Code Scanner.
>>
>> It is not the last bug Brainy has found, but it is the last one I
>> report. I don't have time for that.
>>
>
> How about you release the Brainy Code Scanner then?
>
> "I have so many bugs; in fact, there are so many, I don't even have the
> time to report them! My scanner is so good!"
>
> Or perhaps you should report 'just' the relatively important ones?
>

I think my work does (or used to) benefit to a lot of users, developers
and vendors here; a lot of people, including you.

Nobody supports my work, and I've never asked for anything here about
that. Even though I almost never receive a simple "thank you" for all
the bugs and vulnerabilities I've so far reported, I still expect a
"spiritual thank you" for my work.

But I certainly do not expect that kind of emails you just sent, somehow
trying to either make fun of me or disregard what I'm willing to spend
my spare time on for you.

Developing, improving and maintaining Brainy takes time and energy, as
well as investigating and packaging the bugs and vulnerabilities it
finds. I've so far sent some reports here just because I'm "friendly"
enough, and because modifying a few things for Brainy to properly
understand the OpenBSD code does not require a Herculean work.

Now, I believe that this effort is too much for my spare time. If you
want to say "thanks" to me for reporting this vulnerability, dear Sam,
it's never too late.

Maxime

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Chris Cappuccio
Maxime Villard [[hidden email]] wrote:
>
> Now, I believe that this effort is too much for my spare time. If you
> want to say "thanks" to me for reporting this vulnerability, dear Sam,
> it's never too late.
>

I put here a thanks among others:

Thank you for your effort to help improve the OpenBSD operating system,
to the benefit of its users, developers, and the many others who are
using the code in their own systems. Your work is appreciated, each
commit fixing a bug that you found is perhaps the spiritual thank-you
of which you have detected the subtle presence :)

Chris

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

shun.obsd.tech
In reply to this post by Maxime Villard-2
Hi Maxime,
Hi Sam,

I have been following this thread (and others) for some time.

On Fri, Aug 07, 2015 at 09:55:21PM +0200, Maxime Villard wrote:
> Well, I guess I'll have to admit that I find your attitude extremely
> disrespectful.
I have to agree that the emails are rather short and tend to lack the
subtle cues of human face-to-face interaction. They can easily get
out of hand.

> Le 21/07/2015 12:31, sam a écrit :
> >On Tue, 21 Jul 2015 11:31:44 +0200
> >Maxime Villard <[hidden email]> wrote:
> >
> >>Found by The Brainy Code Scanner.
> >>
> >>It is not the last bug Brainy has found, but it is the last one I
> >>report. I don't have time for that.
> >>
> >
> >How about you release the Brainy Code Scanner then?
Maxime, I have to agree with Sam here. I did check your website, but
have not found any code there. It would be of great help if you would
release it.

> >"I have so many bugs; in fact, there are so many, I don't even have the
> >time to report them! My scanner is so good!"
> >
> >Or perhaps you should report 'just' the relatively important ones?
>
> I think my work does (or used to) benefit to a lot of users, developers
> and vendors here; a lot of people, including you.
Sam, I think Maxime has done good work so far. There is no reason to
mock the work or the person. I thought the motto is "Shut Up and Hack!"
and not "Ridicule and Hack!".

> Nobody supports my work, and I've never asked for anything here about
> that. Even though I almost never receive a simple "thank you" for all
> the bugs and vulnerabilities I've so far reported, I still expect a
> "spiritual thank you" for my work.
Yes, this is a common problem. Hence: Thank you Maxime! Thank you for all
the bugs you (and Brainy) have found so far.


> Developing, improving and maintaining Brainy takes time and energy, as
> well as investigating and packaging the bugs and vulnerabilities it
> finds.
You could share that burden. I am willing to give it a shot.

shun

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Christian Schulte
In reply to this post by Maxime Villard-2
Am 08/07/15 um 21:55 schrieb Maxime Villard:
> Developing, improving and maintaining Brainy takes time and energy, as
> well as investigating and packaging the bugs and vulnerabilities it
> finds. I've so far sent some reports here just because I'm "friendly"
> enough, and because modifying a few things for Brainy to properly
> understand the OpenBSD code does not require a Herculean work.
>
> Now, I believe that this effort is too much for my spare time.

Then why not release that scanner? That effort could be shared. What's
so secret about it? You have been asked several times already.

Regards,
--
Christian Schulte

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Alexey Suslikov
Christian Schulte <cs <at> schulte.it> writes:

> > Now, I believe that this effort is too much for my spare time.
>
> Then why not release that scanner? That effort could be shared. What's
> so secret about it? You have been asked several times already.

Start sharing right now. Brainy OpenBSD page contains info about
lot of bugs already found. There is no secret to start writing
diffs and pushing them.

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Marcus MERIGHI
In reply to this post by Chris Cappuccio
[hidden email] (Chris Cappuccio), 2015.08.07 (Fri) 22:34 (CEST):

> Maxime Villard [[hidden email]] wrote:
> > Now, I believe that this effort is too much for my spare time. If you
> > want to say "thanks" to me for reporting this vulnerability, dear Sam,
> > it's never too late.
>
> I put here a thanks among others:
>
> Thank you for your effort to help improve the OpenBSD operating system,
> to the benefit of its users, developers, and the many others who are
> using the code in their own systems. Your work is appreciated, each
> commit fixing a bug that you found is perhaps the spiritual thank-you
> of which you have detected the subtle presence :)
>
> Chris

Pretty late to say "thank you", I guess... None the less: Thank you!

Bye, Marcus

> !DSPAM:55c51679296674511250856!

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Christian Schulte
In reply to this post by Alexey Suslikov
Am 08/07/15 um 23:46 schrieb Alexey Suslikov:

> Christian Schulte <cs <at> schulte.it> writes:
>
>>> Now, I believe that this effort is too much for my spare time.
>>
>> Then why not release that scanner? That effort could be shared. What's
>> so secret about it? You have been asked several times already.
>
> Start sharing right now. Brainy OpenBSD page contains info about
> lot of bugs already found. There is no secret to start writing
> diffs and pushing them.

I was thinking about automating that process. Scan-before-commit, for
example. Need not be that particular scanner. Some pre-commit analysis
beyond what the compiler can warn about. How can I be sure the issues
found by that scanner are not issues with the scanner itself?

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Ville Valkonen
In reply to this post by Maxime Villard-2
Hello Maxime,

On Aug 7, 2015 10:56 PM, "Maxime Villard" <[hidden email]> wrote:

>
> Well, I guess I'll have to admit that I find your attitude extremely
> disrespectful. But I don't tend to feel particularly offended by this
> kind of things, so it probably does not matter.
>
>
>
> Le 21/07/2015 12:31, sam a écrit :
>>
>> On Tue, 21 Jul 2015 11:31:44 +0200
>> Maxime Villard <[hidden email]> wrote:
>>
>>> Found by The Brainy Code Scanner.
>>>
>>> It is not the last bug Brainy has found, but it is the last one I
>>> report. I don't have time for that.
>>>
>>
>> How about you release the Brainy Code Scanner then?
>>
>> "I have so many bugs; in fact, there are so many, I don't even have the
>> time to report them! My scanner is so good!"
>>
>> Or perhaps you should report 'just' the relatively important ones?
>>
>
> I think my work does (or used to) benefit to a lot of users, developers
> and vendors here; a lot of people, including you.
>
> Nobody supports my work, and I've never asked for anything here about
> that. Even though I almost never receive a simple "thank you" for all
> the bugs and vulnerabilities I've so far reported, I still expect a
> "spiritual thank you" for my work.
>
> But I certainly do not expect that kind of emails you just sent, somehow
> trying to either make fun of me or disregard what I'm willing to spend
> my spare time on for you.
>
> Developing, improving and maintaining Brainy takes time and energy, as
> well as investigating and packaging the bugs and vulnerabilities it
> finds. I've so far sent some reports here just because I'm "friendly"
> enough, and because modifying a few things for Brainy to properly
> understand the OpenBSD code does not require a Herculean work.
>
> Now, I believe that this effort is too much for my spare time. If you
> want to say "thanks" to me for reporting this vulnerability, dear Sam,
> it's never too late.
>
> Maxime

here's my sincerest and humblest appreciation towards you: thanks!

And I'm glad you've spend time to study and report the issues.

--
Regards,
Ville
Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Alexey Suslikov
In reply to this post by Christian Schulte
On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte <[hidden email]> wrote:

> Am 08/07/15 um 23:46 schrieb Alexey Suslikov:
>>
>> Christian Schulte <cs <at> schulte.it> writes:
>>
>>>> Now, I believe that this effort is too much for my spare time.
>>>
>>>
>>> Then why not release that scanner? That effort could be shared. What's
>>> so secret about it? You have been asked several times already.
>>
>>
>> Start sharing right now. Brainy OpenBSD page contains info about
>> lot of bugs already found. There is no secret to start writing
>> diffs and pushing them.
>
>
> I was thinking about automating that process. Scan-before-commit, for
> example. Need not be that particular scanner. Some pre-commit analysis
> beyond what the compiler can warn about. How can I be sure the issues found
> by that scanner are not issues with the scanner itself?
>

Looks like you haven't read carefully. Quote:

"Developing, improving and maintaining Brainy takes time and energy, as
well as investigating and packaging the bugs and vulnerabilities it
finds".

You already have bugs found. Next step in the process is to write diffs.

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Christian Schulte
Am 08/08/15 um 15:06 schrieb Alexey Suslikov:

> On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte <[hidden email]> wrote:
>> Am 08/07/15 um 23:46 schrieb Alexey Suslikov:
>>>
>>> Christian Schulte <cs <at> schulte.it> writes:
>>>
>>>>> Now, I believe that this effort is too much for my spare time.
>>>>
>>>>
>>>> Then why not release that scanner? That effort could be shared. What's
>>>> so secret about it? You have been asked several times already.
>>>
>>>
>>> Start sharing right now. Brainy OpenBSD page contains info about
>>> lot of bugs already found. There is no secret to start writing
>>> diffs and pushing them.
>>
>>
>> I was thinking about automating that process. Scan-before-commit, for
>> example. Need not be that particular scanner. Some pre-commit analysis
>> beyond what the compiler can warn about. How can I be sure the issues found
>> by that scanner are not issues with the scanner itself?
>>
>
> Looks like you haven't read carefully. Quote:
>
> "Developing, improving and maintaining Brainy takes time and energy, as
> well as investigating and packaging the bugs and vulnerabilities it
> finds".
>
> You already have bugs found. Next step in the process is to write diffs.
>

Are you referring to this?

<http://m00nbsd.net/e5ab5f6e59d6a0feb7d1a518acc8233d.html>

_11/ MEMORY LEAK: sys/dev/ic/ti.c rev1.15
      Leak of 'm_new' with MGETHDR() at l.648.

_14/ UNINITIALIZED VARIABLE: sys/arch/hppa64/dev/apic.c rev1.8
      At l.176, 'cnt' is not initialized.

Index: sys/dev/ic/ti.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/ti.c,v
retrieving revision 1.12
diff -u -r1.12 ti.c
--- sys/dev/ic/ti.c 22 Dec 2014 02:28:51 -0000 1.12
+++ sys/dev/ic/ti.c 8 Aug 2015 15:00:55 -0000
@@ -655,6 +655,7 @@

  if (bus_dmamap_load_mbuf(sc->sc_dmatag, dmamap, m_new,
     BUS_DMA_NOWAIT)) {
+ m_freem(m_new);
  m_freem(m);
  return (ENOBUFS);
  }


Reply | Threaded
Open this post in threaded view
|

Possible memory leak in sys/dev/ic/ti.c (was: Re: Brainy: User-Triggerable Kernel Memory Leak in execve())

Christian Schulte
In reply to this post by Alexey Suslikov
While at it. I cannot test this as I do not have corresponding hardware.

Index: sys/dev/ic/ti.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/ti.c,v
retrieving revision 1.12
diff -u -r1.12 ti.c
--- sys/dev/ic/ti.c 22 Dec 2014 02:28:51 -0000 1.12
+++ sys/dev/ic/ti.c 8 Aug 2015 15:36:21 -0000
@@ -561,7 +561,7 @@
  }

  /*
- * Intialize a standard receive ring descriptor.
+ * Initialize a standard receive ring descriptor.
   */
  int
  ti_newbuf_std(struct ti_softc *sc, int i, struct mbuf *m,
@@ -621,7 +621,7 @@
  }

  /*
- * Intialize a mini receive ring descriptor. This only applies to
+ * Initialize a mini receive ring descriptor. This only applies to
   * the Tigon 2.
   */
  int
@@ -655,6 +655,7 @@

  if (bus_dmamap_load_mbuf(sc->sc_dmatag, dmamap, m_new,
     BUS_DMA_NOWAIT)) {
+ m_freem(m_new);
  m_freem(m);
  return (ENOBUFS);
  }

Reply | Threaded
Open this post in threaded view
|

Re: Possible memory leak in sys/dev/ic/ti.c (was: Re: Brainy: User-Triggerable Kernel Memory Leak in execve())

Sebastien Marie-2
Hi,

On Sat, Aug 08, 2015 at 05:39:07PM +0200, Christian Schulte wrote:
> While at it. I cannot test this as I do not have corresponding hardware.
>
> Index: sys/dev/ic/ti.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/ic/ti.c,v
> retrieving revision 1.12
> diff -u -r1.12 ti.c
> --- sys/dev/ic/ti.c 22 Dec 2014 02:28:51 -0000 1.12
> +++ sys/dev/ic/ti.c 8 Aug 2015 15:36:21 -0000

[...]

> @@ -655,6 +655,7 @@
>
>   if (bus_dmamap_load_mbuf(sc->sc_dmatag, dmamap, m_new,
>      BUS_DMA_NOWAIT)) {
> + m_freem(m_new);
>   m_freem(m);
>   return (ENOBUFS);
>   }
>

There is no need to keep m_freem(m): m is NULL in this if() branch (if
condition outside the diff context). There is also a second faulty
m_freem(m) in this file.

Freeing m_new is need as it was just allocated with pool_get(9) (via
MCLGETI or MGETHDR). m_freem() will return it with pool_put(9).

I also keep to comments spelling correction.

Comments or post-lock OK ?
--
Sebastien Marie


Index: dev/ic/ti.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/ti.c,v
retrieving revision 1.15
diff -u -p -r1.15 ti.c
--- dev/ic/ti.c 24 Jun 2015 09:40:54 -0000 1.15
+++ dev/ic/ti.c 9 Aug 2015 07:44:19 -0000
@@ -560,7 +560,7 @@ ti_handle_events(struct ti_softc *sc)
 }
 
 /*
- * Intialize a standard receive ring descriptor.
+ * Initialize a standard receive ring descriptor.
  */
 int
 ti_newbuf_std(struct ti_softc *sc, int i, struct mbuf *m,
@@ -620,7 +620,7 @@ ti_newbuf_std(struct ti_softc *sc, int i
 }
 
 /*
- * Intialize a mini receive ring descriptor. This only applies to
+ * Initialize a mini receive ring descriptor. This only applies to
  * the Tigon 2.
  */
 int
@@ -654,7 +654,7 @@ ti_newbuf_mini(struct ti_softc *sc, int
 
  if (bus_dmamap_load_mbuf(sc->sc_dmatag, dmamap, m_new,
     BUS_DMA_NOWAIT)) {
- m_freem(m);
+ m_freem(m_new);
  return (ENOBUFS);
  }
  } else {
@@ -712,7 +712,7 @@ ti_newbuf_jumbo(struct ti_softc *sc, int
 
  if (bus_dmamap_load_mbuf(sc->sc_dmatag, dmamap, m_new,
     BUS_DMA_NOWAIT)) {
- m_freem(m);
+ m_freem(m_new);
  return (ENOBUFS);
  }
  } else {

Reply | Threaded
Open this post in threaded view
|

sys/arch/{hppa,hppa64}/dev/apic.c cosmetics, Was:Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Alexey Suslikov
In reply to this post by Christian Schulte
Christian Schulte <cs <at> schulte.it> writes:

> _14/ UNINITIALIZED VARIABLE: sys/arch/hppa64/dev/apic.c rev1.8
>       At l.176, 'cnt' is not initialized.

I came up with the following.

--- sys/arch/hppa/dev/apic.c.orig Sun Aug  9 14:16:56 2015
+++ sys/arch/hppa/dev/apic.c Sun Aug  9 14:30:47 2015
@@ -171,12 +171,11 @@
 
  aiv = malloc(sizeof(struct apic_iv), M_DEVBUF, M_NOWAIT);
  if (aiv == NULL) {
- free(cnt, M_DEVBUF, 0);
- return NULL;
+ return (NULL);
  }
 
  cnt = malloc(sizeof(struct evcount), M_DEVBUF, M_NOWAIT);
- if (!cnt) {
+ if (cnt == NULL) {
  free(aiv, M_DEVBUF, 0);
  return (NULL);
  }
--- sys/arch/hppa64/dev/apic.c.orig Sun Aug  9 14:16:47 2015
+++ sys/arch/hppa64/dev/apic.c Sun Aug  9 14:31:14 2015
@@ -173,8 +173,7 @@
 
  aiv = malloc(sizeof(struct apic_iv), M_DEVBUF, M_NOWAIT);
  if (aiv == NULL) {
- free(cnt, M_DEVBUF, 0);
- return NULL;
+ return (NULL);
  }
 
  aiv->sc = sc;
@@ -185,7 +184,7 @@
  aiv->cnt = NULL;
  if (apic_intr_list[irq]) {
  cnt = malloc(sizeof(struct evcount), M_DEVBUF, M_NOWAIT);
- if (!cnt) {
+ if (cnt == NULL) {
  free(aiv, M_DEVBUF, 0);
  return (NULL);
  }

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Philip Guenther-2
In reply to this post by Alexey Suslikov
Awful lot of noise wherein people tell someone else what they should
need to do with their time and their code.


To the best of my knowledge, we've cited and/or thanked Maxime in the
commits fixing the issues he's found, and we're glad to continue to
receive his reports, whether or not they include patches.  My
apologies if we've failed to do so.

The fix for the hppa* apic.c issue is queued up in at least one dev's tree.


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Theo de Raadt
> Awful lot of noise wherein people tell someone else what they should
> need to do with their time and their code.
>
>
> To the best of my knowledge, we've cited and/or thanked Maxime in the
> commits fixing the issues he's found, and we're glad to continue to
> receive his reports, whether or not they include patches.  My
> apologies if we've failed to do so.

Thanks for saying that Philip.

I would like to point out the noise is coming from *users* -- not from
actual developers in the project.

12