### [CVE-2024-56655](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56655)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=a394c160d57f4b083bd904a22802f6fb7f5b3cea%3C%20b8d8f53e1858178882b881b8c09f94ef0e83bf76%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### 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