Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com

CVE-2024-56655

Description

In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: do not defer rule destruction via call_rcunf_tables_chain_destroy can sleep, it can't be used from call_rcucallbacks.Moreover, nf_tables_rule_release() is only safe for error unwinding,while transaction mutex is held and the to-be-desroyed rule was notexposed to either dataplane or dumps, as it deactives+frees withoutthe required synchronize_rcu() in-between.nft_rule_expr_deactivate() callbacks will change ->use countersof other chains/sets, see e.g. nft_lookup .deactivate callback, thesemust be serialized via transaction mutex.Also add a few lockdep asserts to make this more explicit.Calling synchronize_rcu() isn't ideal, but fixing this without is hardand way more intrusive. As-is, we can get:WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x..Workqueue: events nf_tables_trans_destroy_workRIP: 0010:nft_set_destroy+0x3fe/0x5c0Call Trace: nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0In case the synchronize_rcu becomes an issue, we can explore alternatives.One way would be to allocate nft_trans_rule objects + one nft_trans_chainobject, deactivate the rules + the chain and then defer the freeing to thenft destroy workqueue. We'd still need to keep the synchronize_rcu path asa fallback to handle -ENOMEM corner cases though.

POC

Reference

No PoCs from references.

Github

- https://github.com/cku-heise/euvd-api-doc

- https://github.com/fkie-cad/nvd-json-data-feeds