[BUG] net: bridge: received STP timer fields need range validation

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

br_stp_rcv() copies peer-controlled max_age, hello_time and
forward_delay after checking only message_age <= max_age.  It does not
apply the ranges enforced by br_set_max_age(), br_set_hello_time() and
br_set_forward_delay().

Zero and oversized values have several externally visible consequences:

  max_age=0: br_transmit_config() cannot emit configuration BPDUs while
             non-root, while a zero-delay message-age timer forces rapid
             root/designated-port recomputation

  forward_delay=0: a later BLOCKING-port transition uses the zero
                   shortcut and skips LISTENING/LEARNING

  hello_time=0: once the non-root retained value becomes active, the
                hello timer repeatedly re-arms at the rounded minimum
                interval

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1.  A superior-BPDU flood with
max_age=0 and message_age=0 produced:

  max_age=0 in 904/1000 sampled intervals
  attacker root_id in 897/1000 intervals
  68 non-root-to-root restorations
  122 message-age timer expiries

The bridge returned to its configured 600 jiffy max_age and own root ID
after the flood; the impact is rapid flapping and transient suppression
of valid configuration BPDUs, not a permanent takeover.

Received timer fields should be range-checked before they become bridge
or port state.  Candidate BR-035 is canonical; BR-036, BR-037 and
BR-041 are different consequences of the same missing validation.

I found no matching upstream validation patch or CVE.

The BPDU reproducer, verifier, and complete serial log are available on
request.

This was found with a multi-agent workflow; the full
state transition pattern was reproduced in QEMU.

Thanks,
Cheng Yongkang