CVE-2024-56655

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: do not defer rule destruction via call_rcu<br /> <br /> nf_tables_chain_destroy can sleep, it can&amp;#39;t be used from call_rcu<br /> callbacks.<br /> <br /> Moreover, nf_tables_rule_release() is only safe for error unwinding,<br /> while transaction mutex is held and the to-be-desroyed rule was not<br /> exposed to either dataplane or dumps, as it deactives+frees without<br /> the required synchronize_rcu() in-between.<br /> <br /> nft_rule_expr_deactivate() callbacks will change -&gt;use counters<br /> of other chains/sets, see e.g. nft_lookup .deactivate callback, these<br /> must be serialized via transaction mutex.<br /> <br /> Also add a few lockdep asserts to make this more explicit.<br /> <br /> Calling synchronize_rcu() isn&amp;#39;t ideal, but fixing this without is hard<br /> and way more intrusive. As-is, we can get:<br /> <br /> WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x..<br /> Workqueue: events nf_tables_trans_destroy_work<br /> RIP: 0010:nft_set_destroy+0x3fe/0x5c0<br /> Call Trace:<br /> <br /> nf_tables_trans_destroy_work+0x6b7/0xad0<br /> process_one_work+0x64a/0xce0<br /> worker_thread+0x613/0x10d0<br /> <br /> In case the synchronize_rcu becomes an issue, we can explore alternatives.<br /> <br /> One way would be to allocate nft_trans_rule objects + one nft_trans_chain<br /> object, deactivate the rules + the chain and then defer the freeing to the<br /> nft destroy workqueue. We&amp;#39;d still need to keep the synchronize_rcu path as<br /> a fallback to handle -ENOMEM corner cases though.