{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-56655", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-56655" ], "published": "2024-12-27T15:08:24Z", "summary": "netfilter: nf_tables: do not defer rule destruction via call_rcu", "details": "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.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.6.62-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.6.62+rpt-rpi-2712", "binary_version": "1:6.6.62-1+rpt1" }, { "binary_name": "linux-image-6.6.62+rpt-rpi-v6", "binary_version": "1:6.6.62-1+rpt1" }, { "binary_name": "linux-image-6.6.62+rpt-rpi-v7", "binary_version": "1:6.6.62-1+rpt1" }, { "binary_name": "linux-image-6.6.62+rpt-rpi-v7l", "binary_version": "1:6.6.62-1+rpt1" }, { "binary_name": "linux-image-6.6.62+rpt-rpi-v8", "binary_version": "1:6.6.62-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.6.62-1+rpt1": { "linux_commit": "dd2394360860d15146c96635796a75b05bb32b61", "upstream_version": "6.6.62", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.67" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-56655" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5146c27b2780aac59876a887a5f4e793b8949862" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2991dc357a28b61c13ed1f7b59e9251e2b4562fb" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b8d8f53e1858178882b881b8c09f94ef0e83bf76" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b0f013bebf94fe7ae75e5a53be2f2bd1cc1841e3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/27f0574253f6c24c8ee4e3f0a685b75ed3a256ed" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7cf0bd232b565d9852cb25fd094f77254773e048" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b04df3da1b5c6f6dc7cdccc37941740c078c4043" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable path is driven entirely from local interfaces \u2014 nfnetlink/NETLINK_NETFILTER to build a netdev-family basechain with rules, and RTNETLINK to unregister the device that fires the NETDEV_UNREGISTER notifier. No remote peer can drive basechain release.\nAC:L - The attacker owns both sides: it creates the netns, the device, and the ruleset, chooses when to delete the device, and issues concurrent nftables transactions that race the unserialized softirq callback, repeating indefinitely; the sleeping-in-atomic path (`cancel_delayed_work_sync`/`mutex_lock` from an RCU softirq callback) is deterministic and needs no race at all.\nPR:L - nfnetlink only requires `netlink_net_capable(skb, CAP_NET_ADMIN)`, evaluated against the network namespace's user_ns, so an unprivileged local user obtains everything needed via `unshare -Urn` \u2014 including creating and deleting the dummy/veth device that triggers the notifier.\nUI:N - The attacker performs every step itself \u2014 ruleset setup, device removal, and the concurrent transactions; no victim action or pre-existing administrator configuration is needed.\nS:U - Corruption is confined to nf_tables kernel objects within the same kernel security authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - Unserialized `nft_use_dec()` on `set->use`/`chain->use`/`obj->use` races the commit-mutex-protected control plane, so counters underflow and still-referenced sets/chains are freed, yielding a use-after-free whose reclaimed contents the attacker can shape and read back via ruleset dumps.\nI:H - The softirq callback performs `list_del_rcu()` on `table->sets`/`table->chains` and `rhltable_remove()` on `chains_ht` concurrently with control-plane insertions/removals, giving list and rhashtable corruption on top of the UAF \u2014 both standard springboards to controlled kernel writes and control-flow hijack.\nA:H - Sleeping functions (`cancel_delayed_work_sync`, `mutex_lock` via `nf_ct_netns_put`, `nf_tables_chain_destroy`) invoked from an RCU softirq callback produce \"sleeping function called from invalid context\" BUGs and scheduler corruption, and the refcount/list corruption reliably ends in WARNs, oopses, and panics." } } }