syslogd error buffer

2015-01-30 Thread Alexander Bluhm
Hi, The error buffer in syslogd might be too small for the TLS errors. Increase it to 256 bytes and call it ebuf everywhere. ok? bluhm Index: usr.sbin/syslogd/syslogd.c === RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/sy

Re: Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Alexander Bluhm
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

Re: Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Ted Unangst
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

Re: Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Todd C. Miller
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

Re: Allow resuming with closed lid

2015-01-30 Thread Ted Unangst
On Sat, Jan 31, 2015 at 00:24, Ville Valkonen wrote: > Hello Mike and Max, > > my work laptop is running Windows and on there one must press power button > to wake up the machine. If I connect the dots right, current behaviour was > implemented to prevent a "hot bag" problem. Mimicking the Windows

Re: Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Ted Unangst
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

Re: Allow resuming with closed lid

2015-01-30 Thread Ville Valkonen
Hello Mike and Max, my work laptop is running Windows and on there one must press power button to wake up the machine. If I connect the dots right, current behaviour was implemented to prevent a "hot bag" problem. Mimicking the Windows behaviour would also prevent laptop wake ups on a bumpy road.

Re: Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Alexander Bluhm
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

Re: Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Todd C. Miller
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 ---

Re: Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Alexey Suslikov
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

Brainy: User-Triggerable Kernel Memory Leak

2015-01-30 Thread Maxime Villard
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) {

Re: elantech-v4 clickpad support

2015-01-30 Thread Ulf Brosziewski
On 01/30/2015 07:15 AM, Martin Pieuchot wrote: On 30/01/15(Fri) 01:25, Ulf Brosziewski wrote: Probably I was too sceptical about synaptics.c. The bug I observed with the ALPS touchpad seems to be due to a kind of mismatch between the ALPS code in pms and the event handling in wsconscomm. The pat