Re: [PATCH net] net/sched: cls_api: unlink indr cb on a failed bind

[Qihang <q.h.hack.winter@gmail.com>]

The [High] finding is valid, thanks.

flow_block_indr_list is protected by flow_indr_block_lock, and the err_unroll
path ran without it, so the list_del_init() there could race a concurrent
flow_indr_dev_unregister() that walks the list under that lock -- and, if the
notify half unlinks first, list_empty()/list_del_init() could touch a node
that is already off-list.

v2 keeps the unlink but does it under the lock: it adds
flow_indr_block_cb_unlink(), which takes flow_indr_block_lock and calls
list_del_init(), and tcf_block_bind()'s error path calls that instead of
touching indr.list directly.  Taking cb_lock before flow_indr_block_lock is
the order the indirect bind already uses (tcf_block_offload_bind() ->
tcf_block_offload_cmd() -> flow_indr_dev_setup_offload()), so no new lock
nesting is introduced, and the bind and driver-unregister paths are serialized
by rtnl in any case.  flow_block_cb_alloc() now initialises indr.list, so the
helper is a no-op for the direct (non-indirect) callbacks that are never on
the global list.

Rebuilt and re-run under KASAN (arm64): the unpatched kernel panics in
flow_indr_dev_unregister() with a slab-use-after-free, the v2 kernel completes
clean -- the bind still fails with -EOPNOTSUPP and the driver's
flow_indr_dev_unregister() returns 0 with no report.

pw-bot: cr