Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Sun, Aug 09, 2015 at 03:38:25PM -0600, Theo de Raadt wrote: 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. .so let's get rid of the users! I don't understand the purpose of your observations.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Mon, Aug 10, 2015 at 12:23:44PM +0100, Stuart Henderson wrote: On 2015/08/10 11:54, sam wrote: I am also of the opinion that if somebody/a method can discover bugs, they should report them. And if they can't, that method should be disclosed to allow others to continue their work. So you think others should do work for you, right? Whether that work is in discovering and reporting bugs, or in preparing their code for release so you can use it (maybe tidying, writing docs, fielding bug reports, etc.etc.etc.)? This is how the capitalist system has always worked. Exploiting the weakness, folly or fanaticism. OpenBSD is the OS created mostly by a group of people with a strong belief that capitalism and/or democracy is right things for society. What is surprising?
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On 2015/08/12 17:10, Артур Истомин wrote: On Mon, Aug 10, 2015 at 12:23:44PM +0100, Stuart Henderson wrote: On 2015/08/10 11:54, sam wrote: I am also of the opinion that if somebody/a method can discover bugs, they should report them. And if they can't, that method should be disclosed to allow others to continue their work. So you think others should do work for you, right? Whether that work is in discovering and reporting bugs, or in preparing their code for release so you can use it (maybe tidying, writing docs, fielding bug reports, etc.etc.etc.)? This is how the capitalist system has always worked. Exploiting the weakness, folly or fanaticism. OpenBSD is the OS created mostly by a group of people with a strong belief that capitalism and/or democracy is right things for society. What is surprising? Gift economy doesn't seem like capitalism to me. Anyway this is off-topic for tech@. Please redirect any replies to misc, or /dev/null.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Fri, 7 Aug 2015 22:49:50 +0200 shun.obsd.t...@dropcut.net wrote: 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. I'd like to agree with the sentiment here and in the rest of the mail. The lack of body language and tone can result in misunderstandings. I wasn't trying to be disrespectful. It's very easy to pile on a person's comment on the internet. It feels wasteful to develop a seemingly comprehensive and modular code scanner which will inherently find heaps of bugs, and then not release it or allow others to work with it. I am of course grateful that Maxime and others report bugs, but it feels unusual to me that it's acceptable for somebody to consistently be able to find them with a tool, and yet nobody thinks it'd be a good idea to have that tool shared if Maxime is willing. As many here have acknowledged, Maxime's reports are a contribution. So why not seek to have those contributions continue? _That_ was my point, though it was poorly conveyed, falsely appearing to be sarcasm. Le 21/07/2015 12:31, sam a écrit : On Tue, 21 Jul 2015 11:31:44 +0200 Maxime Villard m...@m00nbsd.net 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 regards, sam
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
I'm sorry, I misread you. I wasn't trying to make fun of you or disregard your work. Thanks for reporting this (among other bugs). I am also of the opinion that if somebody/a method can discover bugs, they should report them. And if they can't, that method should be disclosed to allow others to continue their work. On Fri, 7 Aug 2015 21:55:21 +0200 Maxime Villard m...@m00nbsd.net 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 m...@m00nbsd.net 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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On 2015/08/10 11:54, sam wrote: I am also of the opinion that if somebody/a method can discover bugs, they should report them. And if they can't, that method should be disclosed to allow others to continue their work. So you think others should do work for you, right? Whether that work is in discovering and reporting bugs, or in preparing their code for release so you can use it (maybe tidying, writing docs, fielding bug reports, etc.etc.etc.)? Like other developers who replied to this thread, I'm grateful to Maxime for the reports in the past (also I totally understand wanting to stop spending time on this!).
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
I am also of the opinion that if somebody/a method can discover bugs, they should report them. And if they can't, that method should be disclosed to allow others to continue their work. And my opinion is that Sam should back his opinions with lots of money.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
It feels wasteful to develop a seemingly comprehensive and modular code scanner which will inherently find heaps of bugs, and then not release it or allow others to work with it. Sam, since you think throwing opinions out there is valuable Let me give me yours. I think you should talk privately to Maxime and find out how much money he wants from you, to release his tool. Maxime, I suggest you take Sam for all he is worth. That's my opinion in this situation. I came to this opinion because Sam feels so incredibly entitled.
Re: Possible memory leak in sys/dev/ic/ti.c (was: Re: Brainy: User-Triggerable Kernel Memory Leak in execve())
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 - 1.12
+++ sys/dev/ic/ti.c 8 Aug 2015 15:36:21 -
[...]
@@ -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 - 1.15
+++ dev/ic/ti.c 9 Aug 2015 07:44:19 -
@@ -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 {
sys/arch/{hppa,hppa64}/dev/apic.c cosmetics, Was:Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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.cSun 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);
}
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Am 08/09/15 um 23:38 schrieb Theo de Raadt: Awful lot of noise wherein people tell someone else what they should need to do with their time and their code. Sorry. It wasn't meant that way. I was just trying to be helpful to someone saying I don't have time for that and this effort is too much for my spare time. Not a developer. Ok. No more noise from me. Thank you everyone for providing this OS the way you do.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Theo de Raadt deraadt at cvs.openbsd.org writes: I would like to point out the noise is coming from *users* -- not from actual developers in the project. http://www.imdb.com/title/tt1278449/ you'll get the idea.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
ch...@nmedia.net (Chris Cappuccio), 2015.08.07 (Fri) 22:34 (CEST): Maxime Villard [m...@m00nbsd.net] 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!
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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?
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Hello Maxime, On Aug 7, 2015 10:56 PM, Maxime Villard m...@m00nbsd.net 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 m...@m00nbsd.net 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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte c...@schulte.it 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.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Am 08/08/15 um 15:06 schrieb Alexey Suslikov:
On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte c...@schulte.it 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 - 1.12
+++ sys/dev/ic/ti.c 8 Aug 2015 15:00:55 -
@@ -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);
}
Possible memory leak in sys/dev/ic/ti.c (was: Re: Brainy: User-Triggerable Kernel Memory Leak in execve())
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 - 1.12
+++ sys/dev/ic/ti.c 8 Aug 2015 15:36:21 -
@@ -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);
}
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Maxime Villard [m...@m00nbsd.net] 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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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 m...@m00nbsd.net 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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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 m...@m00nbsd.net 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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Jul 21, 2015 9:32 AM, Maxime Villard m...@m00nbsd.net 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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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?
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Tue, 21 Jul 2015 11:31:44 +0200 Maxime Villard m...@m00nbsd.net 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
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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.
Brainy: User-Triggerable Kernel Memory Leak in execve()
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
Re: Brainy: User-Triggerable Kernel Memory Leak
Maxime Villard wrote: FWIW, it would be wise to propagate the fix to the stable branch(es). I guess people use compat-linux. We've decided not to release patches for this. It's not on by default (and i386 only) and as far as we know, mostly used for client machines. i.e., you can crash your own machine. Oh, well, don't do that.
Re: Brainy: User-Triggerable Kernel Memory Leak
FWIW, it would be wise to propagate the fix to the stable branch(es).
I guess people use compat-linux.
Le 31/01/2015 00:33, Alexander Bluhm a écrit :
On Fri, Jan 30, 2015 at 03:57:12PM -0700, Todd C. Miller wrote:
On Fri, 30 Jan 2015 22:55:06 +0100, Alexander Bluhm wrote:
sosetopt() calls m_free() and then it is called again. So it is a
double free.
Whoops, I didn't notice that the non-error case also falls thought
to the bad label. We could just do what sys_setsockopt() does
and zero out m after calling sosetopt().
Let's take this fix. OK bluhm@
- todd
Index: sys/compat/linux/linux_socket.c
===
RCS file: /cvs/src/sys/compat/linux/linux_socket.c,v
retrieving revision 1.59
diff -u -r1.59 linux_socket.c
--- sys/compat/linux/linux_socket.c 21 Jan 2015 13:47:45 - 1.59
+++ sys/compat/linux/linux_socket.c 30 Jan 2015 22:56:40 -
@@ -969,10 +969,8 @@
if (lsa.optval != NULL) {
m = m_get(M_WAIT, MT_SOOPTS);
error = copyin(lsa.optval, mtod(m, caddr_t), lsa.optlen);
-if (error) {
-(void) m_free(m);
+if (error)
goto bad;
-}
m-m_len = lsa.optlen;
}
so = (struct socket *)fp-f_data;
@@ -984,7 +982,10 @@
goto bad;
}
error = sosetopt(so, level, name, m);
+m = NULL;
bad:
+if (m)
+m_free(m);
FRELE(fp, p);
return (error);
}
Re: Brainy: User-Triggerable Kernel Memory Leak
On Fri, Jan 30, 2015 at 02:34:42PM -0700, Todd C. Miller wrote:
I think the simplest fix is to just move the m_free to the bad:
label.
sosetopt() calls m_free() and then it is called again. So it is a
double free.
I would move the so-so_proto check between the if (name == -1) and
the if (lsa.optlen MLEN) block. There m has not been allocated.
Untested as I do not have an i386 right now.
bluhm
Index: sys/compat/linux/linux_socket.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/compat/linux/linux_socket.c,v
retrieving revision 1.59
diff -u -p -r1.59 linux_socket.c
--- sys/compat/linux/linux_socket.c 21 Jan 2015 13:47:45 - 1.59
+++ sys/compat/linux/linux_socket.c 30 Jan 2015 21:51:05 -
@@ -962,6 +962,14 @@ linux_setsockopt(p, v, retval)
error = EINVAL;
goto bad;
}
+ so = (struct socket *)fp-f_data;
+ if (so-so_proto level == IPPROTO_TCP name == TCP_NODELAY
+ so-so_proto-pr_domain-dom_family == AF_LOCAL
+ so-so_proto-pr_protocol == PF_LOCAL) {
+ /* ignore it */
+ error = 0;
+ goto bad;
+ }
if (lsa.optlen MLEN) {
error = EINVAL;
goto bad;
@@ -974,14 +982,6 @@ linux_setsockopt(p, v, retval)
goto bad;
}
m-m_len = lsa.optlen;
- }
- so = (struct socket *)fp-f_data;
- if (so-so_proto level == IPPROTO_TCP name == TCP_NODELAY
- so-so_proto-pr_domain-dom_family == AF_LOCAL
- so-so_proto-pr_protocol == PF_LOCAL) {
- /* ignore it */
- error = 0;
- goto bad;
}
error = sosetopt(so, level, name, m);
bad:
Re: Brainy: User-Triggerable Kernel Memory Leak
I think the simplest fix is to just move the m_free to the bad:
label.
- todd
Index: sys/compat/linux/linux_socket.c
===
RCS file: /cvs/src/sys/compat/linux/linux_socket.c,v
retrieving revision 1.59
diff -u -r1.59 linux_socket.c
--- sys/compat/linux/linux_socket.c 21 Jan 2015 13:47:45 - 1.59
+++ sys/compat/linux/linux_socket.c 30 Jan 2015 21:33:38 -
@@ -969,10 +969,8 @@
if (lsa.optval != NULL) {
m = m_get(M_WAIT, MT_SOOPTS);
error = copyin(lsa.optval, mtod(m, caddr_t), lsa.optlen);
- if (error) {
- (void) m_free(m);
+ if (error)
goto bad;
- }
m-m_len = lsa.optlen;
}
so = (struct socket *)fp-f_data;
@@ -985,6 +983,8 @@
}
error = sosetopt(so, level, name, m);
bad:
+ if (m)
+ (void) m_free(m);
FRELE(fp, p);
return (error);
}
Brainy: User-Triggerable Kernel Memory Leak
Hi,
I put here a bug among others:
-- sys/compat/linux/linux_socket.c --
969 if (lsa.optval != NULL) {
m = m_get(M_WAIT, MT_SOOPTS);
error = copyin(lsa.optval, mtod(m, caddr_t), lsa.optlen);
if (error) {
(void) m_free(m);
goto bad;
}
m-m_len = lsa.optlen;
}
so = (struct socket *)fp-f_data;
if (so-so_proto level == IPPROTO_TCP name == TCP_NODELAY
so-so_proto-pr_domain-dom_family == AF_LOCAL
so-so_proto-pr_protocol == PF_LOCAL) {
/* ignore it */
error = 0;
goto bad;
}
error = sosetopt(so, level, name, m);
bad:
FRELE(fp, p);
return (error);
-
'm' is allocated and filled in, but later the function may jump to 'bad' and
return without freeing it.
'lsa' being user-controllable, it is easy for a local (un)privileged user to
cause the kernel to run out of memory and become unresponsive. OpenBSD 5.6/i386
is affected, and perhaps previous releases.
Exploit here:
http://m00nbsd.net/garbage/OpenBSD_Linux_DoS.c
Binary sample:
http://m00nbsd.net/garbage/OpenBSD_Linux_DoS.tar.gz
Found by my code scanner.
Maxime
Re: Brainy: User-Triggerable Kernel Memory Leak
On Fri, Jan 30, 2015 at 15:57, Todd C. Miller wrote: On Fri, 30 Jan 2015 22:55:06 +0100, Alexander Bluhm wrote: sosetopt() calls m_free() and then it is called again. So it is a double free. Whoops, I didn't notice that the non-error case also falls thought to the bad label. We could just do what sys_setsockopt() does and zero out m after calling sosetopt(). So many diffs to choose from! This does retain the original semantics.
Re: Brainy: User-Triggerable Kernel Memory Leak
Maxime Villard max at M00nBSD.net writes: 'lsa' being user-controllable, it is easy for a local (un)privileged user to cause the kernel to run out of memory and become unresponsive. OpenBSD 5.6/i386 is affected, and perhaps previous releases. compat_linux(8) says: The Linux compatibility feature is active for kernels compiled with the COMPAT_LINUX option and kern.emul.linux sysctl(8) enabled.
Re: Brainy: User-Triggerable Kernel Memory Leak
On Fri, Jan 30, 2015 at 22:55, Alexander Bluhm wrote: On Fri, Jan 30, 2015 at 02:34:42PM -0700, Todd C. Miller wrote: I think the simplest fix is to just move the m_free to the bad: label. sosetopt() calls m_free() and then it is called again. So it is a double free. I would move the so-so_proto check between the if (name == -1) and the if (lsa.optlen MLEN) block. There m has not been allocated. Untested as I do not have an i386 right now. This will change the sematnics slightly for programs that, for example, set those options but then pass in an invalid pointer. I think that's acceptable, however. Well behaved programs will not notice the difference. ok
Re: Brainy: User-Triggerable Kernel Memory Leak
On Fri, 30 Jan 2015 22:55:06 +0100, Alexander Bluhm wrote:
sosetopt() calls m_free() and then it is called again. So it is a
double free.
Whoops, I didn't notice that the non-error case also falls thought
to the bad label. We could just do what sys_setsockopt() does
and zero out m after calling sosetopt().
- todd
Index: sys/compat/linux/linux_socket.c
===
RCS file: /cvs/src/sys/compat/linux/linux_socket.c,v
retrieving revision 1.59
diff -u -r1.59 linux_socket.c
--- sys/compat/linux/linux_socket.c 21 Jan 2015 13:47:45 - 1.59
+++ sys/compat/linux/linux_socket.c 30 Jan 2015 22:56:40 -
@@ -969,10 +969,8 @@
if (lsa.optval != NULL) {
m = m_get(M_WAIT, MT_SOOPTS);
error = copyin(lsa.optval, mtod(m, caddr_t), lsa.optlen);
- if (error) {
- (void) m_free(m);
+ if (error)
goto bad;
- }
m-m_len = lsa.optlen;
}
so = (struct socket *)fp-f_data;
@@ -984,7 +982,10 @@
goto bad;
}
error = sosetopt(so, level, name, m);
+ m = NULL;
bad:
+ if (m)
+ m_free(m);
FRELE(fp, p);
return (error);
}
Re: Brainy: User-Triggerable Kernel Memory Leak
On Fri, Jan 30, 2015 at 03:57:12PM -0700, Todd C. Miller wrote:
On Fri, 30 Jan 2015 22:55:06 +0100, Alexander Bluhm wrote:
sosetopt() calls m_free() and then it is called again. So it is a
double free.
Whoops, I didn't notice that the non-error case also falls thought
to the bad label. We could just do what sys_setsockopt() does
and zero out m after calling sosetopt().
Let's take this fix. OK bluhm@
- todd
Index: sys/compat/linux/linux_socket.c
===
RCS file: /cvs/src/sys/compat/linux/linux_socket.c,v
retrieving revision 1.59
diff -u -r1.59 linux_socket.c
--- sys/compat/linux/linux_socket.c 21 Jan 2015 13:47:45 - 1.59
+++ sys/compat/linux/linux_socket.c 30 Jan 2015 22:56:40 -
@@ -969,10 +969,8 @@
if (lsa.optval != NULL) {
m = m_get(M_WAIT, MT_SOOPTS);
error = copyin(lsa.optval, mtod(m, caddr_t), lsa.optlen);
- if (error) {
- (void) m_free(m);
+ if (error)
goto bad;
- }
m-m_len = lsa.optlen;
}
so = (struct socket *)fp-f_data;
@@ -984,7 +982,10 @@
goto bad;
}
error = sosetopt(so, level, name, m);
+ m = NULL;
bad:
+ if (m)
+ m_free(m);
FRELE(fp, p);
return (error);
}
