lib/55599: libpcap gets SIGBUS on strictly aligned CPUs

[uwe%stderr.spb.ru@localhost]

>Number:         55599
>Category:       lib
>Synopsis:       libpcap gets SIGBUS on strictly aligned CPUs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 23 01:35:00 +0000 2020
>Originator:     Valery Ushakov
>Release:        NetBSD current
>Organization:
>Environment:
NetBSD felix 9.99.71 NetBSD 9.99.71 (FELIX) #0: Sun Aug 23 02:32:34 MSK 2020  uwe@majava:/home/uwe/work/netbsd/cvs/src/sys/arch/landisk/compile/FELIX landisk
>Description:
libpcap imported on 2019/10/01 gets SIGBUS trying to compile some
filter expressions.

In gencode.c in gen_bcmp():

-		bpf_int32 w = ((bpf_int32)p[0] << 24) |
-		    ((bpf_int32)p[1] << 16) | ((bpf_int32)p[2] << 8) | p[3];
 
-		tmp = gen_cmp(cstate, offrel, offset + size - 4, BPF_W, w);
+		tmp = gen_cmp(cstate, offrel, offset + size - 4, BPF_W,
+		    (bpf_int32)EXTRACT_32BITS(p));

where EXTRACT_32BITS is defined in extract.h and the definition
depends on LBL_ALIGN (defined "if unaligned access fails").
Unfortunately we ship pregenerated config.h that has

/* #undef LBL_ALIGN */

So when you try e.g.

    tcpdump ether host xx:...:xx

that code tries to access unaligned 32-bit value.  I see that on sh3
and macallan@ confirmed he sees that on sparc64.

In arm unaligned accesses don't necessarily SIGBUS but do weird
things, so there the bug will be less obvious.

I originally ran into this trying to run wpa_supplicant which uses a
filter expression with ether src/dst and crashes.


>How-To-Repeat:
# tcpdump ether host xx:...:xx

>Fix:
I'm not sure what a good fix might be.  We can either always define
LBL_ALIGN as we do e.g. for tcpdump.  We can provide -DLBL_ALIGN from
Makefile.inc .if the cpu is strictly aligned.  We can also do #ifdef
dance in the pregenerated config.h which is a bit more hassle during
the import but doesn't rely on magic in the makefiles and so is
preferrable, IMO.  The same fix probably need to be applied to tcpdump
then too.