cve/published/2024/CVE-2024-56655.mbox

From bippy-1.2.0 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@kernel.org>
To: <linux-cve-announce@vger.kernel.org>
Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.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 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/5146c27b2780aac59876a887a5f4e793b8949862
	https://git.kernel.org/stable/c/2991dc357a28b61c13ed1f7b59e9251e2b4562fb
	https://git.kernel.org/stable/c/b8d8f53e1858178882b881b8c09f94ef0e83bf76
	https://git.kernel.org/stable/c/b0f013bebf94fe7ae75e5a53be2f2bd1cc1841e3
	https://git.kernel.org/stable/c/27f0574253f6c24c8ee4e3f0a685b75ed3a256ed
	https://git.kernel.org/stable/c/7cf0bd232b565d9852cb25fd094f77254773e048
	https://git.kernel.org/stable/c/b04df3da1b5c6f6dc7cdccc37941740c078c4043