On 4/14/26 10:05 AM, Ido Schimmel wrote: > On Mon, Apr 13, 2026 at 05:08:46PM +0800, Ren Wei wrote: >> From: Zhengchuan Liang <[email protected]> >> >> Local FDB entries can be rewritten in place by `fdb_delete_local()`, which >> updates `f->dst` to another port or to `NULL` while keeping the entry >> alive. Several bridge RCU readers inspect `f->dst`, including >> `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. >> >> These readers currently load `f->dst` multiple times and can therefore >> observe inconsistent values across the check and later dereference. >> In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change >> `f->dst` after the NULL check and before the `port_no` dereference, >> leading to a NULL-ptr-deref. >> >> Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each >> affected RCU reader and using that snapshot for the rest of the access >> sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` >> with `WRITE_ONCE()` so the readers and writer use matching access patterns. > > Sashiko is complaining [1] about missing READ_ONCE() annotations in some > places, but I can handle them in net-next in a similar fashion to commit > 3e19ae7c6fd6 ("net: bridge: use READ_ONCE() and WRITE_ONCE() compiler > barriers for fdb->dst").
I agree they can be handled separately, because they don't look harmful. I think a 'net' patch could be used for such follow-up (data race) /P
