[Bug 296598] inbound ipsec packets get tracked via outer ip header when the tunnel runs over if_wg

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D296598

--- Comment #6 from Lars Kr=C3=A4mer <[email protected]> ---
I think I may have found the cause for this, and why it is only present with
if_wg.
Running this:
dtrace -x nolibs -qn '
fbt::enc_hhook:entry
/arg0 =3D=3D 3/ {
  this->enc =3D *(uint8_t *)((uintptr_t)arg3 + 25);
  this->mp_ptr =3D *(uintptr_t *)arg3;
  this->m =3D *(uintptr_t *)this->mp_ptr;
  this->mdata =3D *(uintptr_t *)(this->m + 16);
  this->mnext =3D *(uintptr_t *)(this->m + 0);
  this->mnext_len =3D *(int *)(this->mnext + 24);
  this->ipp =3D *(uint8_t *)(this->mdata + 9);
  this->mlen =3D *(int *)(this->m + 24);
  printf("enc_hhook IPSEC_IN stage=3D%d m=3D%p m_data=3D%p m_len=3D%d m_nex=
t=3D%p
m_next_len=3D%d ip_p=3D%d\n",
    this->enc, this->m, this->mdata, this->mlen, this->mnext, this->mnext_l=
en,
this->ipp);
}'
Gives me this output:
enc_hhook IPSEC_IN stage=3D1 m=3Dfffff80022ed4700 m_data=3Dfffff80022ed4768=
 m_len=3D20
m_next=3Dfffff800635c6a00 m_next_len=3D60 ip_p=3D4
enc_hhook IPSEC_IN stage=3D2 m=3Dfffff80022ed4700 m_data=3Dfffff80022ed4768=
 m_len=3D0
m_next=3Dfffff800635c6a00 m_next_len=3D60 ip_p=3D4

The packet is stored inside an mbuf chain. The head only contains the outer=
 IP
header, 20 bytes.
ipsec4_common_input_cb calls m_striphdr to remove 20 bytes of IP header from
the packet.
This just sets the length of the mbuf to zero.
The mbuf head is now length zero.

This mbuf gets passed down like this until it reaches pf_test, where the IP
header gets read via mtod.
This is basically a pointer cast, reading the old header data from the buff=
er.


This also explains why the issue is only present with if_wg, and not with
wireguard-go.
The dtrace from above with wireguard-go looks like this (without m_next_len,
this time):
enc_hhook IPSEC_IN stage=3D1 m=3Dfffff80058132800 m_data=3Dfffff8005813285c=
 m_len=3D60
m_next=3D0 ip_p=3D4
enc_hhook IPSEC_IN stage=3D2 m=3Dfffff80058132800 m_data=3Dfffff80058132870=
 m_len=3D40
m_next=3D0 ip_p=3D6

wireguard-go hands over the packet as a single mbuf, probably because it's
coming from userspace, avoiding the bug.

--=20
You are receiving this mail because:
You are the assignee for the bug.=