mirror of
https://github.com/0xMarcio/cve.git
synced 2025-11-30 18:56:19 +00:00
27 lines
2.8 KiB
Markdown
27 lines
2.8 KiB
Markdown
### [CVE-2024-56655](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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: <TASK> 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
|
|
|