Re: [PATCH net] tipc: raise the minimum bearer MTU to fit tunnel and crypto overhead

On Mon, Oct 12, 2026, Tung Quang Nguyen wrote:

This approach is not good because  it uses hard-coded size of TIPC crypto
header (32).
The size should be calculated based on tipc_ehdr.
Could you please test below general approach ?

Hi Tung,

Agreed, deriving it from EMSG_OVERHEAD is better.  I tested your
approach on 602042bf29f6 (arm64, QEMU, KASAN), applied on its own
without my patch:

- Builds cleanly with W=1 for net/tipc/, with CONFIG_TIPC_CRYPTO=y and
  with CONFIG_TIPC_CRYPTO=n.

- Same reproducer as before (node A with 40 cluster-scope publications
  and MTU 1500, node B enabling its bearer on a veth with the MTU
  below):

    config            peer MTU   bearer on B         link   KASAN
    TIPC_CRYPTO=y        100     refused (too low)    -       none
    TIPC_CRYPTO=y        171     refused (too low)    -       none
    TIPC_CRYPTO=y        172     enabled              up      none
    TIPC_CRYPTO=y       1500     enabled              up      none
    TIPC_CRYPTO=n        100     refused (too low)    -       none
    TIPC_CRYPTO=n        139     refused (too low)    -       none
    TIPC_CRYPTO=n        140     enabled              up      none
    TIPC_CRYPTO=n       1500     enabled              up      none

  So the floor is 172 with crypto and 140 without, the same values as
  my patch, and the KASAN report from the unpatched kernel is gone.

One limitation: the reproducer lowers the MTU of B's device, so it
exercises the bearer-enable check.  The max_pkt negotiation path in
tipc_link_proto_rcv() uses the same value through
tipc_bearer_min_mtu(), but I did not forge RESET/ACTIVATE messages to
hit it separately.

Would you like me to send a v2 based on your approach (with your
Co-developed-by/Signed-off-by), or do you prefer to post it yourself
with a Reported-by/Tested-by from me?

Thanks,
Joas