[BUG] net: bridge: CFM period conversion overflows 32 bits

[Cheng Yongkang <teel4res@gmail.com>]

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