[{"id":3681922,"web_url":"http://patchwork.ozlabs.org/comment/3681922/","msgid":"","list_archive_url":null,"date":"2026-04-24T09:52:11","subject":"Re: [PATCH nf 1/1] netfilter: ebtables: fix OOB read in\n compat_mtw_from_user","submitter":{"id":1025,"url":"http://patchwork.ozlabs.org/api/people/1025/","name":"Florian Westphal","email":"fw@strlen.de"},"content":"Ren Wei wrote:\n> From: Luxiao Xu \n> \n> The function compat_mtw_from_user() converts ebtables extensions from\n> 32-bit user structures to kernel native structures. However, it lacks\n> proper validation of the user-supplied match_size/target_size.\n> \n> When certain extensions are processed, the kernel-side translation\n> logic may perform memory accesses based on the extension's expected\n> size. If the user provides a size smaller than what the extension\n> requires, it results in an out-of-bounds read as reported by KASAN.\n> \n> This fix introduces a check to ensure match_size is at least as large\n> as the extension's required compatsize. This covers matches, watchers,\n> and targets, while maintaining compatibility with standard targets.\n> \n> Fixes: 81e675c227ec (\"netfilter: ebtables: add CONFIG_COMPAT support\")\n> Cc: stable@kernel.org\n> Reported-by: Yuan Tan \n> Reported-by: Yifan Wu \n> Reported-by: Juefei Pu \n> Reported-by: Xin Liu \n> Signed-off-by: Luxiao Xu \n> Signed-off-by: Ren Wei \n> ---\n> net/bridge/netfilter/ebtables.c | 11 +++++++++++\n> 1 file changed, 11 insertions(+)\n> \n> diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c\n> index aea3e19875c6..80cd0233c088 100644\n> --- a/net/bridge/netfilter/ebtables.c\n> +++ b/net/bridge/netfilter/ebtables.c\n> @@ -1977,6 +1977,11 @@ static int compat_mtw_from_user(const struct compat_ebt_entry_mwt *mwt,\n> \t\tif (IS_ERR(match))\n> \t\t\treturn PTR_ERR(match);\n> \n> +\t\tif (match_size < match->compatsize) {\n> +\t\t\tmodule_put(match->me);\n> +\t\t\treturn -EINVAL;\n> +\t\t}\n> +\n\nAre you sure this catches all bad requests? AFAIR compatsize is 0\nin most cases, which bypasses this test.\n\nshould this be:\n\nu16 csize = match->compatsize ? : match->matchsize;\n...\nif (match_size < csize) {\n...\n\n?\n\n@Pablo: I think the 32bit compat layer should be removed in -next, or\nat least strongly discouraged and slated for removal soon.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","netfilter-devel@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-12170-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=91.216.245.30","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=strlen.de","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=strlen.de"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g27Zb44pkz1yD5\n\tfor ; Fri, 24 Apr 2026 19:53:43 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id C9A98301DCE1\n\tfor ; Fri, 24 Apr 2026 09:52:22 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 765D0348866;\n\tFri, 24 Apr 2026 09:52:22 +0000 (UTC)","from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc\n [91.216.245.30])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id DAB423264E2\n\tfor ; Fri, 24 Apr 2026 09:52:19 +0000 (UTC)","by Chamillionaire.breakpoint.cc (Postfix, from userid 1003)\n\tid 5ECD960425; Fri, 24 Apr 2026 11:52:17 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777024342; cv=none;\n b=MpD560smoswzXSwv9TurXv4vDPBp4Xt3jOSJLfZq7fIYhi5n8eIKqTQ3VMGSG6rFR0Dr4fCVSkQKptzTE1QPYJIeCOabDlvksazV42vHly+mp5WhVIxYA2gdUlhvXxqHX5YxGMQPDIpn3mxAhhzcBfr089LkWIX8U5kxTz+U2EE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777024342; c=relaxed/simple;\n\tbh=XyHFxLW08zH56ek4JeZXjLTlwXrhoacLwNL/r7W01w4=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=g7G4MQc00d2SbIgXHF1A/f8ePqkVZIXbgNMHPDen1fQxzthUyWYgc4uWZ3s5QPWrkxhLVxHKsLH/A575XqpSTnfLaS3pvB2LL5qw5JA5v1h0Mmj4Uw51+FUfpF0a7nUbS5SuwB3uSsN/3bzx3jxgeUlVkgjCizvlCZuSqE6cfhU=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=strlen.de;\n spf=pass smtp.mailfrom=strlen.de; arc=none smtp.client-ip=91.216.245.30","Date":"Fri, 24 Apr 2026 11:52:11 +0200","From":"Florian Westphal ","To":"Ren Wei ","Cc":"netfilter-devel@vger.kernel.org, bridge@lists.linux.dev,\n\tpablo@netfilter.org, phil@nwl.cc, razor@blackwall.org,\n\tidosch@nvidia.com, davem@davemloft.net, edumazet@google.com,\n\tkuba@kernel.org, pabeni@redhat.com, horms@kernel.org,\n\tyuantan098@gmail.com, yifanwucs@gmail.com, tomapufckgml@gmail.com,\n\tbird@lzu.edu.cn, rakukuip@gmail.com","Subject":"Re: [PATCH nf 1/1] netfilter: ebtables: fix OOB read in\n compat_mtw_from_user","Message-ID":"","References":"\n <4e714f6189f9691fa5980087ce378a57cf625976.1776834093.git.rakukuip@gmail.com>","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"\n <4e714f6189f9691fa5980087ce378a57cf625976.1776834093.git.rakukuip@gmail.com>"}}]