cbcvebase.
CVE-2024-56655
published 2024-12-27

CVE-2024-56655: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not defer rule destruction via call_rcu nf_tables_chain_destroy…

PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.23%
13.4th percentile
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not defer rule destruction via call_rcu nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks. Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between. nft_rule_expr_deactivate() callbacks will change ->use counters of other chains/sets, see e.g. nft_lookup .deactivate callback, these must 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 hard and 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_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Call Trace: nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0 In case the synchronize_rcu becomes an issue, we can explore alternatives. One way would be to allocate nft_trans_rule objects + one nft_trans_chain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though.

Affected

20 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.6-1 (forky)linux 6.12.6-1 (forky)
linuxlinux
linuxlinux
linuxlinux>= 558f503f707f481bbf40efa74a938b8021df841d < 2991dc357a28b61c13ed1f7b59e9251e2b4562fb2991dc357a28b61c13ed1f7b59e9251e2b4562fb
linuxlinux>= 6.11.8 < 6.126.12
linuxlinux>= 6.6.61 < 6.6.676.6.67
linuxlinux>= 9eee6097ffb26cdd2adb988c0d378fa0d650c737 < 5146c27b2780aac59876a887a5f4e793b89498625146c27b2780aac59876a887a5f4e793b8949862
linuxlinux>= a394c160d57f4b083bd904a22802f6fb7f5b3cea < b8d8f53e1858178882b881b8c09f94ef0e83bf76b8d8f53e1858178882b881b8c09f94ef0e83bf76
linuxlinux>= bfd05c68e4c6320304e9f371ffa356b6e4b9cc53 < 27f0574253f6c24c8ee4e3f0a685b75ed3a256ed27f0574253f6c24c8ee4e3f0a685b75ed3a256ed
linuxlinux>= c03d278fdf35e73dd0ec543b9b556876b9d9a8dc < 7cf0bd232b565d9852cb25fd094f77254773e0487cf0bd232b565d9852cb25fd094f77254773e048
linuxlinux>= c03d278fdf35e73dd0ec543b9b556876b9d9a8dc < b04df3da1b5c6f6dc7cdccc37941740c078c4043b04df3da1b5c6f6dc7cdccc37941740c078c4043
linuxlinux>= e6c32a64d61184c2bdf89442b3d31ef530afba34 < b0f013bebf94fe7ae75e5a53be2f2bd1cc1841e3b0f013bebf94fe7ae75e5a53be2f2bd1cc1841e3
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.12.6-16.12.6-1
linuxlinux_kernel>= 0 < 6.12.6-16.12.6-1
linuxlinux_kernel>= 6.11.8 < 6.12.66.12.6
linuxlinux_kernel>= 6.6.61 < 6.6.676.6.67
msrcazl3_kernel_6.6.64.2-9_on_azure_linux_3.0
msrcazl3_kernel_6.6.76.1-1_on_azure_linux_3.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.