(Not tested, but that just seems sensible.)

In D19960#1253517, @thj wrote:

I don't think there are any links with an mtu to carry 65,575, but if there
ever are I would expect to find some bugs.

I'm not sure this is sufficient. It is still possible for tcpdump to have started, but not gotten to the point of actually opening the pflog device.

In D54382#1242817, @madpilot wrote:

Forgot to add references:

[1] 9e792f7ef7298080c058fbc2d36a4e60e596dae9

DIOCGETRULENV takes the write lock as well but I believe this is only
required when clearing rule counters. (It might not be required even
then, on platforms where counter increment is done atomically.) Acquire
the read lock if that is not the case.

I believe that was accidentally broken by 96b29c7f0cffd377a757ad8ccc0cdd8fcb96d0dd, which fixed the issue of jails being unable to go away while they still had ovpn interfaces in them. It fixed that, but also removed the VNET_SYSUNINIT that prevented this leak.

Ah, thanks. With the original patch reverted this applies and works as expected.
I'm not all that familiar with this code, but it works and I don't see any obvious problems (and it addresses the problem CHERI found, being that we used more than 'new_size' from 'new_base'.)

What's this based on? It doesn't seem to want to apply to FreeBSD main (f9500e75791cf793904c80ca4a52433afd585a23).