Hi all, The unrestricted IFLA_BRIDGE_CFM_CC_CCM_TX_PERIOD u32 is multiplied by 1000000 in 32-bit arithmetic before conversion to jiffies. The same expression is used for start, update and keep-alive.
On a HZ=100 build this produces: requested 4295 s -> about 40 ms requested 2^26 s -> zero requested 54369991 s -> effectively non-expiring saturation The netlink request succeeds, and RTM_GETLINK reports the requested period rather than the encoded duration. CCM transmission can therefore stop after one frame, stop before emitting any frame, or continue far longer than requested. Observed on Linux v7.3, commit 08ab31164c55f20c7a2653de3186ae333470e2c1, CONFIG_HZ=100: period 10: 3 frames, active for the control interval period 4295: 1 frame, cleared after 1115 ms period 2^26: 0 frames, cleared after 1 ms period 54369991: 4 frames, still active after 3507 ms All four requests returned success. The conversion needs a 64-bit intermediate or an explicit bounded duration check before storing the CCM end time. An October 2026 iproute2 CFM discussion notes that the CCM-TX period overflows above 4294 seconds, but I found no corresponding kernel patch or CVE. Candidate BR-009 is a separate queue/save synchronization race in the same state fields. The reproducer and full logs are available on request. This was found with a multi-agent workflow; the overflow signatures were reproduced in QEMU. Thanks, Cheng Yongkang
