Hello,
On Mon, Jan 18, 2021 at 04:47:08PM +0100, Alexander Bluhm wrote: > Hi, > > pflog(4) tries to log the translated packet with rdr-to, nat-to, > and af-to applied. Therefore it creates a mbuf chain on the stack > with a partial copy. This might have been a good idea for plain > IPv4 10 years ago. But now the concept fails miserably due to: > > - IP options > - extension header > - NAT46 af-to > - fragmented mbuf chains > > Even the plain IPv4 case does not work. Usually the length checks > in pf_setup_pdesc() reject the faked mbuf on the stack and we goto > copy. Some special cases call pf_translate() and it fails miserably. > syzkaller has found such a case. > > https://urldefense.com/v3/__https://syzkaller.appspot.com/bug?id=9415f8d0a6f176a629daaa910c431498f5e8aa99__;!!GqivPVa7Brio!L_T-G9Xpq8csLhGKsq5JBtP3aiZTolKPbjXvKMYTPeU-hSLuh2QEfd5HgHl7Pt_MSP3vnGNQ$ > > > After trying to understand this code for a week, I came to the > conclusion that it is broken beyond repair. The funny part is, > when I remove pflog_mtap(), the pflog output in the cases tested > by regress/sys/net/pflog stays the same. I've tried a 'log' and 'log all' variant with rule: pass out log (all) on vio1 inet from vio2:network to any flags S/SA nat-to (vio1) round-robin and I also could spot _no_ difference in 'tcpdump -i pflog0' output. similar test with rdr-to also has not revealed any difference. > > Remove this undead code to log the packet as it is. > > ok? > simple is better. OK sashan@
