[Devel] [PATCH vz7] ms/netfilter: nf_tables: stricter validation of element data

[Devel] [PATCH vz7] ms/netfilter: nf_tables: stricter validation of element data

[Konstantin Khorenko]

From: Pablo Neira Ayuso <pablo@netfilter.org>

Make sure element data type and length do not mismatch the one specified
by the set declaration.

Fixes: 7d7402642eaf ("netfilter: nf_tables: variable sized set element keys / data")
Reported-by: Hugues ANGUELKOV <hanguelkov@randorisec.fr>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6)

Backport notes:
 - the check is done in nft_add_set_elem(), desc is d2 there.

7d7402642eaf from Fixes: is not here, but the old check has a similar
hole: it skips the length test for verdict maps. An NFT_DATA_VALUE
element shorter than struct nft_verdict gets a data extension of d2.len
bytes, and nft_set_elem_init() copies set->dlen bytes into it.

nft_setelem_parse_data() came with ms commit fdb9c405e35b ("netfilter:
nf_tables: allow up to 64 bytes in the set element data area") in v5.8,
so here the element data is still parsed inline in nft_add_set_elem().

dtype is compared with d2.type, the type of the element data, as
upstream compares it with desc->type. Comparing it with set->dtype
instead would be wrong both ways:
 - for a value map set->dtype holds the datatype id from userspace,
   e.g. 7 for ipv4_addr from nft, not NFT_DATA_VALUE, so every element
   add to such a map fails with -EINVAL;
 - for a verdict map dtype always equals set->dtype, so an
   NFT_DATA_VALUE element of sizeof(struct nft_verdict) bytes is still
   taken as a verdict with a chain pointer from userspace.

The closest stable backport, 4.14.y commit acd3e18fbcae ("netfilter:
nf_tables: stricter validation of element data"), compares with
desc->type as well:
https://git.kernel.org/stable/c/acd3e18fbcae6c5f9d79d75455569fc132227162

CVE-2022-34918
https://virtuozzo.atlassian.net/browse/VSTOR-154185

Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
CVE-2022-34918 fix for the vz7 kernel.

https://virtuozzo.atlassian.net/browse/VSTOR-154185

Assisted-by: LLM
---
 net/netfilter/nf_tables_api.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 66137ce5e6482..2b17434b3770e 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -3683,13 +3683,20 @@ static int nft_add_set_elem(struct nft_ctx *ctx, struct nft_set *set,
 	}
 
 	if (nla[NFTA_SET_ELEM_DATA] != NULL) {
+		u32 dtype;
+
 		err = nft_data_init(ctx, &data, sizeof(data), &d2,
 				    nla[NFTA_SET_ELEM_DATA]);
 		if (err < 0)
 			goto err2;
 
 		err = -EINVAL;
-		if (set->dtype != NFT_DATA_VERDICT && d2.len != set->dlen)
+		if (set->dtype == NFT_DATA_VERDICT)
+			dtype = NFT_DATA_VERDICT;
+		else
+			dtype = NFT_DATA_VALUE;
+
+		if (dtype != d2.type || d2.len != set->dlen)
 			goto err3;
 
 		dreg = nft_type_to_reg(set->dtype);

---
base-commit: 78c10c447efc7633a8e4260fe7dc33e1cb4bb4d2
change-id: 20261109-b4-prep-khorenko-vstor-154185-nf_tables-element-data-76fec8329998

Best regards,
--  
Konstantin Khorenko,
Virtuozzo Linux Kernel Team

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel