pflog(4) tried to log the translated packet with rdr-to, nat-to,
authorbluhm <bluhm@openbsd.org>
Tue, 19 Jan 2021 22:22:23 +0000 (22:22 +0000)
committerbluhm <bluhm@openbsd.org>
Tue, 19 Jan 2021 22:22:23 +0000 (22:22 +0000)
commit2cbebc019f52ca82e5fb8c4ec5d5ed5614c8fef5
tree2ef1ff1e9c84ca82e88d04907150502821d2eebe
parentc317fba5c295aa6b03fb700374cc80a25dbabd29
pflog(4) tried to log the translated packet with rdr-to, nat-to,
and af-to addresses and ports applied.  Therefore it created a mbuf
chain on the stack with a partial copy.  This is too complicated
for IP options, extension header, NAT46 af-to, and fragmented mbuf
chains.  It even caused a crash in syzkaller.  Usually the length
checks in pf_setup_pdesc() rejected the faked mbuf and the goto
copy logged the packet unmodified.  Remove the pflog_mtap() function
and call bpf_mtap_hdr() directly.  As the old buggy code was bypassed
in most cases, tcpdump(8) output of pflog does not change.
Uncondionally log the unmodified packet.
Reported-by: syzbot+947e89e06ac3fec187d0@syzkaller.appspotmail.com
OK sashan@
sys/net/if_pflog.c
sys/net/pf.c