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
