Hello,
i think there is a possible NULL dereference in uvm_fault_lower.
uvm_fault.c:1282 assigns
uobjpage = PGO_DONTCARE;
uobj = NULL;
and then tries to lock on line 1288
locked = uvmfault_relock(ufi);
if this fails it continues to line 1324 which will NULL dereference
On Thu, 4 Nov 2021 23:55:22 +1100
Jonathan Gray wrote:
> On Thu, Nov 04, 2021 at 12:02:21PM +, Laurence Tratt wrote:
> > On Thu, Nov 04, 2021 at 10:24:07PM +1100, Jonathan Gray wrote:
> >
> > Hello Jonathan,
> >
> > >> I updated my amd64 machine from a snapshot from about 2 weeks ago to
This is just a heads up, that i'm hitting a stubbed out function.
While testing a port update (love2d)
Not quite sure how, the only GEM related ioctl, that is called,
is DRM_IOCTL_GEM_CLOSE according to ktrace.
OpenBSD 6.9-beta (GENERIC.MP) #340: Thu Feb 18 10:41:54 MST 2021
On Mon, 14 Dec 2020 10:41:41 +0100
Benjamin Baier wrote:
> On Sun, 13 Dec 2020 14:47:26 -0700
> "Theo de Raadt" wrote:
>
> > Jason McIntyre wrote:
> >
> > > On Sun, Dec 13, 2020 at 05:58:08PM +, Brian Kelk wrote:
> > > > Hi.
> >
On Sun, 13 Dec 2020 14:47:26 -0700
"Theo de Raadt" wrote:
> Jason McIntyre wrote:
>
> > On Sun, Dec 13, 2020 at 05:58:08PM +, Brian Kelk wrote:
> > > Hi.
> > >
> > > The man page for passwd says that the length of a password must be
> > > less than a specified value. Less than or equal to
On Tue, 14 Jan 2020 01:47:48 +0100
Jeremie Courreges-Anglas wrote:
> Advertizing support for IP_ADDRESS makes little sense if we know we
> won't implement it. Maybe the use of #ifdef TCPCONN should be extended,
> but I don't even know what's the deal between IP_ADDRESS and TCPCONN
> (somehow
On Mon, 13 Jan 2020 20:45:04 +0100
Jeremie Courreges-Anglas wrote:
> ... I think IP_ADDRESS should just go.
> Upstream doesn't seem to care much about it:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=7611
I agree.
> Index: src/CvtStdSel.c
>
On Sat, 11 Jan 2020 19:52:22 +0100
Matthieu Herrb wrote:
> On Sat, Jan 11, 2020 at 05:47:05PM +, Stuart Henderson wrote:
> > On 2020/01/11 17:24, Matthieu Herrb wrote:
> > > On Tue, Jan 07, 2020 at 09:00:04PM +0100, Benjamin Baier wrote:
> > >
> > > H
On Wed, 8 Jan 2020 04:31:42 -0500
Thomas Dickey wrote:
> On Wed, Jan 08, 2020 at 09:01:32AM +0100, Benjamin Baier wrote:
> ...
> > > Thomas Dickey wrote:
> ...
> > > > Reading the source, it seems that the client is asking for the target
> > > > wit
>Synopsis: xterm pledge dns violation
>Category: X11 / libc? / ports?
>Environment:
System : OpenBSD 6.6
Details : OpenBSD 6.6-current (GENERIC.MP) #0: Mon Jan 6 20:17:42
CET 2020
ntional, because userland programmers shouldn't
> always have vnodes in their faces -- notice we don't mention anywhere
> that in unix unlinked files still work via pre-opened fd's?)
>
> There maybe a solution to this. fd's opened post-unveil, as a
> result of a traversal, could carr
Hi,
using openat(2) after unveil(2) seems to misbehave.
Isolated test case below. I expect the code to succesfully end with
exit code 0 but it fails with exit code 6.
Greetings Ben
#include
#include
#include
#include
#include
#include
int try_openat(int, const char*);
int
main(int
etwork.
Used to work out-of-the-box with 255.255.255.255.
> On 09/03/16 22:00, Benjamin Baier wrote:
> >> Synopsis: Invalid route entry outside subnet / Used to work
> >> Category: Kernel panic
> >> Environment:
> > System : OpenBSD 6.0
> > Detail
>Synopsis: Invalid route entry outside subnet / Used to work
>Category: Kernel panic
>Environment:
System : OpenBSD 6.0
Details : OpenBSD 6.0-current (GENERIC.MP) #2400: Sun Aug 28
12:30:07 MDT 2016
On Sat, 4 Jun 2016 14:22:15 +0100
Edd Barrett wrote:
> I spent a fair amount of time trying to understand what was going wrong in the
> EDID code, but alas, no cigar.
>
> Reposting on bugs@ so it doesn't get lost/forgotten. Here's an updated bug
> report using the latest
On Thu, 28 Jan 2016 08:22:16 +
Jason McIntyre wrote:
> On Wed, Jan 27, 2016 at 08:24:09PM +0100, f...@fuz.su wrote:
> > The manual page chmod(2) states about the chmod() system call:
> >
> > If mode ISVTX (the sticky bit) is set on a file, it is ignored.
> >
> >
On Sat, 31 Jan 2015 12:43:03 +0100
Martin Pieuchot mpieuc...@nolizard.org wrote:
On 18/01/15(Sun) 17:39, Benjamin Baier wrote:
usbhidaction(1) still works fine with these changes.
as for my stock usbhidctl(1) it now shows
$ usbhidctl -f /dev/uhid1 -l
Volume_Decrement=1
usbhidctl
Well of course this is the right patch
Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.347
diff -u -p -r1.347 dhclient.c
--- dhclient.c 16 Jan 2015 06:39:56 - 1.347
+++ dhclient.c
On Fri, 30 Jan 2015 00:12:13 +0100 (CET)
rvdb...@fam-vdberg.eu wrote:
Synopsis:Possible memory leak in dhclient program
Category:system
Environment:
System : OpenBSD 5.6
Details : OpenBSD 5.6-stable (GENERIC.MP) #0: Thu Jan 15 17:43:09
CET 2015
Synopsis: usbhidctl(1) -l does not work/loop
Category: user
Environment:
System : OpenBSD 5.7
Details : OpenBSD 5.7-beta (GENERIC.MP) #0: Fri Jan 16 17:26:49 CET
2015
short test shows a2p shipped with OpenBSD starts seg-faulting at
$ python2.7 -c print 'A' * 16383 | a2p
On 11/16/2014 11:44 PM, up201407...@alunos.dcc.fc.up.pt wrote:
Hello. My name is Federico Manuel Bento, and i have found what it
_appears_ to be a buffer overflow on the a2p (awk2perl)
Hello.
ftp://ftp.openbsd.org/pub/OpenBSD/5.6/i386/INSTALL.linux is missing.
Found because http://www.openbsd.org/faq/faq4.html#Multibooting links to it.
Same here.
CC md5/libcrypto_la-md5_dgst.lo
In file included from md5/md5_locl.h:98:0,
from md5/md5_dgst.c:60:
md5/md5_dgst.c: In function 'md5_block_data_order':
./md32_common.h:237:66: error: right-hand operand of comma expression
has no effect [-Werror=unused-value]
So we should take all our hardware mixers, and crank them to full
volume right at boot time.
IMO, this is the best option.
Do you have a stereo system connected to your PC? I would not
made this the default. Start low and if you want a loud default
setting, use mixerctl.conf
If hardware
24 matches
Mail list logo