This CVE exposes a bounds-checking gap in TIPC's netlink interface where MTU values get silently truncated when they exceed what a u16 can hold. The vulnerability lives in two paths: media configuration and bearer configuration, both of which accept MTU values via netlink attributes, store them in u16 fields, and perform minimum-bound validation (MTU must be positive) while omitting the upper-bound check that u16 requires.
When you pass 65536 as MTU, it becomes 0 in the stored field, and that zero triggers a division-by-zero panic in tipc_link_set_queue_limits. That's the visible failure. But values between 65537 and 131071 are worse—they don't crash, they silently produce wrong but non-zero MTU values that propagate through every function reading l->mtu or l->advertised_mtu. There is no crash log, no alert, just corrupted internal state.
The fix adds upper-bound checks in both handlers, but this is a canonical case of patching one instance without addressing the validation model. The question to audit is: where else does TIPC accept numeric parameters via netlink that get assigned to smaller integer types without equivalent upper-bound validation? The same pattern that produced this bug—checking minimums but not maximums—may exist elsewhere in the subsystem.
Exploitability is straightforward: any user who can create a user namespace can configure TIPC media and bearer settings without CAP_NET_ADMIN, making this a local denial-of-service vector available to unprivileged users. This expands the practical severity beyond what the crash alone would suggest.
Audit tipc_link_create() and every direct caller. Validate at the assignment point, not just at the netlink boundary, because future code paths that bypass the netlink handlers will carry the same gap forward.