Re: cu hw.ucomnames / cu.c 1.29 problem

2024-02-09 Thread aphekz
On Fri, Feb 09, 2024 at 09:52:53PM -0500, Kenneth Westerback wrote: > Looks correct to me. The value returned by get_ucomnames() is only > passed to find_ucom() where it is checked against NULL. > > aphekz, if you can confirm this works for you I can commit. yes, it works aphekz > >

code reading, possible derefence on non-malloced data?

2024-02-09 Thread Peter J. Philipp
Hi, I'd like you to just quickly look at the following to files: /usr/src/lib/libradius/radius.c 61 for (; attr < end; ATTRS_ADVANCE(attr)) { 62 if (attr->length < 2) 63 return (-1); and it's header file

Re: cu hw.ucomnames / cu.c 1.29 problem

2024-02-09 Thread Kenneth Westerback
Makes sense to me. Ken On Fri, Feb 9, 2024, 10:44 PM Theo de Raadt wrote: > Kenneth Westerback wrote: > > > Looks correct to me. The value returned by get_ucomnames() is only > > passed to find_ucom() where it is checked against NULL. > > Alternative diff in the kernel, *in addition* to

Re: cu hw.ucomnames / cu.c 1.29 problem

2024-02-09 Thread Theo de Raadt
Kenneth Westerback wrote: > Looks correct to me. The value returned by get_ucomnames() is only > passed to find_ucom() where it is checked against NULL. Alternative diff in the kernel, *in addition* to the other diff. On a ucom-supporting kernel, if there are no matching devices the sysctl

Re: cu hw.ucomnames / cu.c 1.29 problem

2024-02-09 Thread Kenneth Westerback
Looks correct to me. The value returned by get_ucomnames() is only passed to find_ucom() where it is checked against NULL. aphekz, if you can confirm this works for you I can commit. Ken "Theo de Raadt" writes: > Yes, this code should not fail in that circumstance. It should silently >

Re: cu hw.ucomnames / cu.c 1.29 problem

2024-02-09 Thread Theo de Raadt
Yes, this code should not fail in that circumstance. It should silently carry on. Note the code: #if NUCOM > 0 case HW_UCOMNAMES: { If the kernel has no USB com, the sysctl code is disabled. That is why it MUST silently carry on. But your bug report is incomplete. Where is the full

cu hw.ucomnames / cu.c 1.29 problem

2024-02-09 Thread aphekz
hi ~ > cu -l cua00 -s 115200 (on -stable) quits with an error cu: hw.ucomnames: Operation not supported as there is only com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo and no any ucom devices on that machine so as below there is no hw.ucomnames value ~ > sysctl hw.ucomnames sysctl:

Re: vmd/vionet: locked lladdr regression

2024-02-09 Thread Klemens Nanni
On Fri, Feb 09, 2024 at 05:00:44PM -0500, Dave Voutila wrote: > Turns out I had a bug in my packet injection logic. Locked addr forces > use of the copy mode (i.e. not the zero-copy mode) and my logic was > thinking the packet being read was an "injected" packet from the dhcp > intercept. I don't

Re: vmd/vionet: locked lladdr regression

2024-02-09 Thread Dave Voutila
Klemens Nanni writes: > kern.version=OpenBSD 7.4-current (GENERIC.MP) #1667: Wed Feb 7 20:09:35 MST > 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > 'locked addr' in `switch' block yields > vm/foo/vionet0: vionet_rx_copy: invalid injected packet

Re: vmd/vionet/vioblk: network + disk regression

2024-02-09 Thread Klemens Nanni
On Fri, Feb 09, 2024 at 10:02:29AM -0500, Dave Voutila wrote: > Try this diff. There was an issue in the order of closing disk fds. I > also noticed we're not closing the sockets when closing the data fds, so > that's added into virtio_dev_closefds(). > > With this i can boot a guest that uses a

Re: vmd/vionet/vioblk: network + disk regression

2024-02-09 Thread Dave Voutila
Klemens Nanni writes: > kern.version=OpenBSD 7.4-current (GENERIC.MP) #1667: Wed Feb 7 20:09:35 MST > 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > This boots fine: > > # cat /tmp/vm.conf > vm foo { > disable >

Re: Super Slow Bug

2024-02-09 Thread Dragonking
Alright I got no idea how to update my BIOS but I'll look into it, and see what happens when I do so. Thanks for that. Once again sorry for my attitude earlier was just spammed with a bunch of school work in a short amount of time. It seems updating BIOS on asus laptops is pretty easy so thats

Re: vmd/vionet/vioblk: network + disk regression

2024-02-09 Thread Klemens Nanni
On Fri, Feb 09, 2024 at 10:20:12AM +, Klemens Nanni wrote: > This terminates the VM immediately after startup: > > # cat /tmp/vm.conf > vm foo { > disable > disk /tmp/linux.qcow2 > interface > } Backing this out makes the VM start,

Re: potential buffer overflow in usr.sbin/tcpdump/print-gre.c

2024-02-09 Thread Moritz Buhl
I compared the code in the commit with the code in the tree and I think the code never was affected by CVE-2016-7939 since all length checks use the buffer length. However, should you know a gre packet that crashes tcpdump(8) please don't hesitate and contact secur...@openbsd.org. mbuhl On Fri,

vmd/vionet/vioblk: network + disk regression

2024-02-09 Thread Klemens Nanni
kern.version=OpenBSD 7.4-current (GENERIC.MP) #1667: Wed Feb 7 20:09:35 MST 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP This boots fine: # cat /tmp/vm.conf vm foo { disable disk /tmp/linux.qcow2 }

vmd/vionet: locked lladdr regression

2024-02-09 Thread Klemens Nanni
kern.version=OpenBSD 7.4-current (GENERIC.MP) #1667: Wed Feb 7 20:09:35 MST 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP 'locked addr' in `switch' block yields vm/foo/vionet0: vionet_rx_copy: invalid injected packet object Minimal reproducer from my

Re: Super Slow Bug

2024-02-09 Thread Stuart Henderson
On 2024/02/08 19:50, Dragonking wrote: > I dont feel like adding all the context because it spans two reddit posts, that's not a great attitude to have when you're asking for help :( > whoever gets this email sorry but here the reddit posts are: >