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
