{"vulnerability": "cve-2024-56655", "sightings": [{"uuid": "4ee9b696-28b3-4e6c-9f36-db9b0fb7aa14", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-56655", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lecbzqxdsz2m", "content": "", "creation_timestamp": "2024-12-27T15:20:18.907798Z"}, {"uuid": "4ccc9062-14a2-4352-a9f1-3ac3c153968c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-56655", "type": "seen", "source": "https://t.me/cvedetector/13781", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56655 - Linux Kernel Netfilter NF_Tables RCU Race Condition Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56655 \nPublished : Dec. 27, 2024, 3:15 p.m. | 32\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: nf_tables: do not defer rule destruction via call_rcu  \n  \nnf_tables_chain_destroy can sleep, it can't be used from call_rcu  \ncallbacks.  \n  \nMoreover, nf_tables_rule_release() is only safe for error unwinding,  \nwhile transaction mutex is held and the to-be-desroyed rule was not  \nexposed to either dataplane or dumps, as it deactives+frees without  \nthe required synchronize_rcu() in-between.  \n  \nnft_rule_expr_deactivate() callbacks will change ->use counters  \nof other chains/sets, see e.g. nft_lookup .deactivate callback, these  \nmust be serialized via transaction mutex.  \n  \nAlso add a few lockdep asserts to make this more explicit.  \n  \nCalling synchronize_rcu() isn't ideal, but fixing this without is hard  \nand way more intrusive.  As-is, we can get:  \n  \nWARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x..  \nWorkqueue: events nf_tables_trans_destroy_work  \nRIP: 0010:nft_set_destroy+0x3fe/0x5c0  \nCall Trace:  \n   \n nf_tables_trans_destroy_work+0x6b7/0xad0  \n process_one_work+0x64a/0xce0  \n worker_thread+0x613/0x10d0  \n  \nIn case the synchronize_rcu becomes an issue, we can explore alternatives.  \n  \nOne way would be to allocate nft_trans_rule objects + one nft_trans_chain  \nobject, deactivate the rules + the chain and then defer the freeing to the  \nnft destroy workqueue.  We'd still need to keep the synchronize_rcu path as  \na fallback to handle -ENOMEM corner cases though. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-27T16:51:51.000000Z"}]}