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,
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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.
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
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.
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
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 -
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
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
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
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
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
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);
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
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
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
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
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
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
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
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
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) {
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
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
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
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
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.
40 matches
Mail list logo