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
> > >
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.
>
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
> 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 priv
> 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.
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
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 extremel
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
Theo de Raadt 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.
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 mu
> 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 n
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 includ
Christian Schulte 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 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 re
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 -
Am 08/08/15 um 15:06 schrieb Alexey Suslikov:
On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte wrote:
Am 08/07/15 um 23:46 schrieb Alexey Suslikov:
Christian Schulte schulte.it> writes:
Now, I believe that this effort is too much for my spare time.
Then why not release that scanner? Th
On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte wrote:
> Am 08/07/15 um 23:46 schrieb Alexey Suslikov:
>>
>> Christian Schulte 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. W
Hello Maxime,
On Aug 7, 2015 10:56 PM, "Maxime Villard" 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 écri
Am 08/07/15 um 23:46 schrieb Alexey Suslikov:
Christian Schulte 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 sha
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
Christian Schulte 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 cont
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
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 lac
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 Op
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 wrote:
Found by The
sam 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.
Searchin
On Tue, 21 Jul 2015 11:31:44 +0200
Maxime Villard 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 a
Ville Valkonen gmail.com> writes:
> On Jul 21, 2015 9:32 AM, "Maxime Villard" 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 peop
On Jul 21, 2015 9:32 AM, "Maxime Villard" wrote:
>
> Hi,
> I put here a bug among others:
>
> - sys/kern/kern_exec.c -
>
> char *pathbuf = NULL;
>
> [...]
>
> pathbuf = pool_get(&namei_pool, PR_WAITOK);
>
> [..
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 (p
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()
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 "b
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. W
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 c
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 mo
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 (ls
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
---
Maxime Villard 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 featur
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) {
40 matches
Mail list logo
