| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2024122749-CVE-2024-56655-e94f@gregkh> Date: Fri, 27 Dec 2024 16:06:52 +0100 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: CVE-2024-56655: netfilter: nf_tables: do not defer rule destruction via call_rcu Description =========== 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: <TASK> 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. The Linux kernel CVE team has assigned CVE-2024-56655 to this issue. Affected and fixed versions =========================== Issue introduced in 6.6.61 with commit bfd05c68e4c6320304e9f371ffa356b6e4b9cc53 and fixed in 6.6.67 with commit 27f0574253f6c24c8ee4e3f0a685b75ed3a256ed Issue introduced in 6.12 with commit c03d278fdf35e73dd0ec543b9b556876b9d9a8dc and fixed in 6.12.6 with commit 7cf0bd232b565d9852cb25fd094f77254773e048 Issue introduced in 6.12 with commit c03d278fdf35e73dd0ec543b9b556876b9d9a8dc and fixed in 6.13-rc3 with commit b04df3da1b5c6f6dc7cdccc37941740c078c4043 Issue introduced in 6.11.8 with commit cb401e5799e0acacb405f2128097e9c4ccf82f8a Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2024-56655 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: include/net/netfilter/nf_tables.h net/netfilter/nf_tables_api.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/27f0574253f6c24c8ee4e3f0a685b75ed3a256ed https://git.kernel.org/stable/c/7cf0bd232b565d9852cb25fd094f77254773e048 https://git.kernel.org/stable/c/b04df3da1b5c6f6dc7cdccc37941740c078c4043
Powered by blists - more mailing lists