On Wed, Sep 09, 2026 at 06:23:32PM -0600, Zack Newman wrote:
> I tested two Linux WireGuard peers, and they don't suffer from this MTU
> "overflow" problem. I believe a bug was introduced by @cjeker in commit
> c061998[^1]:
> 
> - plaintext_len = min(WG_PKT_WITH_PADDING(m->m_pkthdr.len), t->t_mtu);
> + plaintext_len = WG_PKT_WITH_PADDING(m->m_pkthdr.len);
> 
> Linux, FreeBSD, and older OpenBSD versions clamp the plaintext padding
> so that the MTU is not exceeded.
> 
> [^1]: https://github.com/openbsd/src/commit/c06199859734d958552a581d72b4c0f910e68d7c

It may be indeed a problem that we don't clip the the packet to t->t_mtu
but at the same time the code in wg_encap() is certainly not doing this
right since that bit caused pool panics for various people.  

The problem is that padding by 16 bytes and a MTU of 1420 don't play well
since 1420 is not a multiple of 16. The code tries to hard to be smart and
then spectacularly fails.

I don't really use wg(4) but I'm willing to help to ensure the mbuf logic
is sane.
-- 
:wq Claudio