[BUG] net: bridge: CFM CCM transmission state races with delayed work

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

br_cfm_cc_ccm_tx() and ccm_tx_work_expired() mutate
mep->ccm_tx_end and mep->cc_ccm_tx_info.period without a common lock.
The start path also queues ccm_tx_dwork before saving the new
cc_ccm_tx_info.

One reachable interleaving is:

  writer: store ccm_tx_end
  writer: queue ccm_tx_dwork
  worker: observe an expired end, store period = 0, do not requeue
  writer: store the requested nonzero period

The final state reports an active nonzero CCM period, but no delayed
work remains and no CCM frames are sent.  The keep-alive branch has the
mirror interleaving: it can update ccm_tx_end and return success while
the worker subsequently clears period and stops transmitting.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1.  A self-checking userspace
program exercised the start-path ordering and found six phantom states
in 384 attempts:

  start_period=67108864
  probe_period=12738873
  two readbacks remained 12738873
  keepalive returned success
  final period remained 12738873 with no pending work

Four independent snapshot-VM boots produced 98 explicit confirmations
in total.  KASAN and UBSAN were clean, as expected for a control-plane
liveness defect.  The target lacked KCSAN, so the report does not rely
on a KCSAN warning: the queue-before-save ordering is directly visible
in source and the inconsistent externally visible state was observed.

The worker and configuration path need serialization, and the new CCM
state should be stored before the delayed work can execute.

This is distinct from candidate BR-038, which reports the 32-bit period
conversion overflow in the same state fields; that arithmetic bug needs
a separate fix.

I found no matching upstream fix or CVE.

The self-contained reproducer and complete logs are available on
request.

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

Thanks,
Cheng Yongkang