[patch] Fail execve on environment duplicates

Duplicate environment variables have been a source of bugs, so perhaps the kernel should fail an execve with an invalid envp. Diff below checks that each environment string contains a '=' and that there are no duplicates up to the equals sign. So far I haven't noticed any breakage except for a

Re: pf: remove pfr_{sin,sin6,mask} globals

Hello Patrick, your diff looks OK to me. thanks and regards sasha On Mon, May 08, 2017 at 02:56:55PM +0200, Patrick Wildt wrote: > Hi, > > in order to reduce globals so that we can run more parts of pf in > parallel, this diff removes the pfr_sin, pfr_sin6 and pfr_mask > globals. Those are

Re: ocspcheck size_t printing

You are correct. Patch committed. Thanks! -Bob On Mon, May 08, 2017 at 08:20:57PM +0200, Jonas 'Sortie' Termansen wrote: > Hi, > > When upgrading to libressl-2.5.4 I noticed a couple -Wformat errors due > to this code assuming size_t is of type long when it was actually int on > this 32-bit

Re: relayd: incomplete response from a TLS-accelerated apache

Compiling relayd with -DDEBUG=3 and watching the output gave me nothing. No errors what so ever about out of buffers or something else. However, removing 'socket buffer 65536’ solved my problem. Br > 8 maj 2017 kl. 13:27 skrev Maxim Bourmistrov : > > Hey, > I

OpenBSD Errata: May 8th, 2017 (libssl)

Errata patches for libssl have been released for OpenBSD 6.1 and 6.0. Incorrect DTLS cookie handling can result in a NULL pointer dereference. Binary updates for the amd64 and i386 platforms are available via the syspatch utility. Source code patches can be found on the respective errata pages:

Re: Correct capable baseband in dmesg for RTL8188E chips

In that case I'd rather just have a general else like you said. I'll commit it in a bit if you don't beat me to it :) thanks! On 19:27 Mon 08 May , Stefan Sperling wrote: > On Mon, May 08, 2017 at 05:35:26PM +0100, Ricardo Mestre wrote: > > Hi tech@ > > > > During stsp@'s effort to merge

IPv6 IPsec transport pf

Hi, IPv6 IPsec transport mode does not work if pf is enabled. The problem is that the decrypted packets in the input path are not checked with pf(4). So if you have stateful filtering on enc0 (the default) direction aware protocols like ping or TCP do not pass. Only the output packets are

ocspcheck size_t printing

Hi, When upgrading to libressl-2.5.4 I noticed a couple -Wformat errors due to this code assuming size_t is of type long when it was actually int on this 32-bit system. Here's a patch against cvs that fixes the issue and also prints the variableas unsigned type. Jonas Index: ocspcheck.c

Re: Correct capable baseband in dmesg for RTL8188E chips

On Mon, May 08, 2017 at 05:35:26PM +0100, Ricardo Mestre wrote: > Hi tech@ > > During stsp@'s effort to merge rtwn(4) and urtwn(4), more specifically since > r1.6 of /cvs/src/sys/dev/ic/rtwn.c, my urtwn(4) device started showing in > dmesg > with a capable baseband of 0T0R (only noticed it

Correct capable baseband in dmesg for RTL8188E chips

Hi tech@ During stsp@'s effort to merge rtwn(4) and urtwn(4), more specifically since r1.6 of /cvs/src/sys/dev/ic/rtwn.c, my urtwn(4) device started showing in dmesg with a capable baseband of 0T0R (only noticed it today!): urtwn0: MAC/BB RTL8188EU, RF 6052 0T0R, address xx:xx:xx:xx:xx:xx Since

ipv6 mapped address output

Hi, Checking for IPv4 mapped addresses is a bit inconsistent in the output path. So I would like to: - Use the common switch(af) construct for af specific code in tcp_usrreq(PRU_CONNECT). - Add a EAFNOSUPPORT default case. - Do not check for mapped addresses, this is done in in6_pcbconnect().

Re: uip_socket.c: issues when using sendmsg() with small send buffers and the new 6.1 control message (IP_SENDSRCADDR)

On Fri, Apr 21, 2017 at 08:43:11AM +, Markert, Alexander wrote: > In our opinion either EMSGSIZE should be returned instead in this case (like > e.g. FreeBSD 11.0 does) or OpenBSD should reserve some space (comparable to > MSG_OOB) in addition to the maximum size of the socket's send buffer

Re: fix iwm command wait vs interface reset

On Mon, May 08, 2017 at 03:54:38PM +0200, Mark Kettenis wrote: > > Date: Mon, 8 May 2017 15:36:11 +0200 > > From: Stefan Sperling > > > > In iwm_send_cmd(), look at the generation counter instead of the STOPPED > > flag > > to determine whether the interface was reset while we

Re: arm64 lock: no userland progress, several procs in wchan "vp"

On 2017/05/04 00:31, Mark Kettenis wrote: > > Date: Wed, 3 May 2017 21:05:24 +0100 > > From: Stuart Henderson > > > > On 2017/05/03 15:12, Mark Kettenis wrote: > > > > Date: Wed, 3 May 2017 13:51:22 +0100 > > > > From: Stuart Henderson > > > > > > >

Re: fix iwm command wait vs interface reset

> Date: Mon, 8 May 2017 15:36:11 +0200 > From: Stefan Sperling > > In iwm_send_cmd(), look at the generation counter instead of the STOPPED flag > to determine whether the interface was reset while we were sleeping. The flag > will be set if the interface is still down when the

Re: uip_socket.c: issues when using sendmsg() with small send buffers and the new 6.1 control message (IP_SENDSRCADDR)

On 26/04/17(Wed) 12:29, Markert, Alexander wrote: > Hi, > > actually you are right that this issue is related to control messages and not > to the send buffer length. But the length of the control message is checked > in combination with the data to be sent in uip_socket.c: > > Let's assume we

fix iwm command wait vs interface reset

In iwm_send_cmd(), look at the generation counter instead of the STOPPED flag to determine whether the interface was reset while we were sleeping. The flag will be set if the interface is still down when the task wakes up, but the interface could already be up again in which case the flag will be

boot: put debug printfs inside of defines

Hi, most if (debug) prints are inside of an ifdef guard, but those two apparently aren't. The amd64 efiboot for instance does only define debug if EFI_DEBUG is set, which it is not per default. So it won't build. We can either guard those checks as well or remove the EFI_DEBUG ifdef guarding

pf: remove pfr_{sin,sin6,mask} globals

Hi, in order to reduce globals so that we can run more parts of pf in parallel, this diff removes the pfr_sin, pfr_sin6 and pfr_mask globals. Those are instead allocated on the stack. ok? Patrick diff --git a/sys/net/pf_table.c b/sys/net/pf_table.c index 708bd68cbcd..2cdff265ff5 100644 ---

Re: routing socket panic

> From: "Ted Unangst" > Date: Sun, 07 May 2017 21:29:16 -0400 > > Ted Unangst wrote: > > Mike Belopuhov wrote: > > > > So there is something in the tree that doesn't like the mbuf packet > > > > header growth and decides to color outside the lines. > > > > > > > > > >

Re: mbuf padding and alignment

On Mon, May 08, 2017 at 13:38 +0200, Mark Kettenis wrote: > So the reason mikeb@'s mbuf changes caused issues is that the way we > define struct mbuf is inherently fragile because it doesn't take > structure padding into account. Adding an int64_t member to struct > pkthdr changed the alignment

Re: splsoftnet() -> NET_ASSERT_LOCKED()

On Mon, May 08, 2017 at 11:04:56AM +0200, Martin Pieuchot wrote: > With my previous diff to remove pfctlinput() false positive we can now > turn the last splsoftnet() into an assert. > > pfctlinput() is only used on OpenBSD for PRC_REDIRECT_HOST. It is > always called during the input path, so

Re: Kill useless pfctlinput()

On Mon, May 08, 2017 at 10:55:04AM +0200, Martin Pieuchot wrote: > This diff removes a false positive from bluhm@'s lock analyser. This is > the last piece to turn the NET_LOCK() on. > > pfctlinput(PRC_IFDOWN, ...) is a noop. None of the *_ctlinput() handler > present in the kernel handle

mbuf padding and alignment

So the reason mikeb@'s mbuf changes caused issues is that the way we define struct mbuf is inherently fragile because it doesn't take structure padding into account. Adding an int64_t member to struct pkthdr changed the alignment from 4 bytes to 8 bytes on most 32-bit architectures (but not

relayd: incomplete response from a TLS-accelerated apache

Hey, I investigate a problem were TLS-asselerated machine response is incomplete. I was able to reproduce this on OpenBSD 5.9, 6.0 and 6.1. Test on 5.8 is about to be. Following env I have: relay1: relayd machine web1: apache 2.2.31 serving the request client1: requester relay1 is configured

Re: pf: percpu anchor stacks

On 28/03/17(Tue) 13:02, Alexandr Nedvedicky wrote: > [...] > > > > - s/test_status/action/ as it's done everywhere else? > > I've opted to test_status, because it's something different to 'action' > as we use it in current code. I agree with you for test_status. What about naming the

splsoftnet() -> NET_ASSERT_LOCKED()

With my previous diff to remove pfctlinput() false positive we can now turn the last splsoftnet() into an assert. pfctlinput() is only used on OpenBSD for PRC_REDIRECT_HOST. It is always called during the input path, so with the NET_LOCK() held. ok? Index: kern/uipc_domain.c

Kill useless pfctlinput()

This diff removes a false positive from bluhm@'s lock analyser. This is the last piece to turn the NET_LOCK() on. pfctlinput(PRC_IFDOWN, ...) is a noop. None of the *_ctlinput() handler present in the kernel handle PRC_IFDOWN. And all of do nothing because inet{,6}ctlerrmap == 0. The two