CVE-2026-68297

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.

Reviewed through automated stages and approved by a human before publication.