From: Pablo Neira Ayuso <[email protected]>
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 <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
(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 <[email protected]>
---
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
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
