From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1426B33E35C for ; Wed, 17 Jun 2026 22:47:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781736451; cv=none; b=K0C18qXvAMy2WNXcRnLyUGyJXIYRMdik6gGq7egrStxLAtKBeFJvyjxVPRCoxHVkpiQMqMOPwTd9sdzyI452CDlgaAH3bsa8lhL+EOiofOtEzEwft6fg8JZqfLNOpfc6kb6abIA36Ea2kyAmdJe5sKWZH1gryKqjxF1jfqvLN28= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781736451; c=relaxed/simple; bh=yM6kJR9+j6KBxCtaM2cYf0AuV1XZewak4TynnyV+IJM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=gKX4k1UQswyDH5EaXdMT8CN7vjJ6crc72gbnLu2/UoRrCn32JJsqdoSPM2vrtHiFqcfXMiuvCZ8FBqhguC8qi/uacy7BTq4KXpZRTitBqq6q5rhzXLiqwK8lZXgXuwde8DtA3t0Lnj/o/J5xt+utuA3YrpD4oZHzJShaHYx8m7Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=db7lAJfT; arc=none smtp.client-ip=209.85.216.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="db7lAJfT" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-36d8b644473so171699a91.3 for ; Wed, 17 Jun 2026 15:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781736449; x=1782341249; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=+/ktcGtRdK8bOsxRZ/ZQSsMpZyLcq8Ea6Ees+j5Oy2A=; b=db7lAJfT2508SaTj8ZaJjvJLGtMNAIzbaFykFFUCY8wP618uagcRrrNNmxGCZI1wWV Xw2Gq/Db/wjFscO5Fz6w/0EKdvNwRwwR/iva/mAXSoJRjowls7i4zmbYVveHKwDfQepg 2f34Rt+a7XFf0qm2rt+cQu37oKu5WqZsbElmktuArryLBZSF7uAh1TudDCb433+LhG5T 7pbYH+LzPubGcShnXaLnquhrnZzdYketiAhHBW2z0q/u+emd9ja/d1/c8lNtRG2yldhU 9QFm8tpCXHKwjRPBadweLHaMC7NmIgrfAV5oRBnR6o77i1tvOlMMTbPD/tLBHH+LTA+k xwVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781736449; x=1782341249; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+/ktcGtRdK8bOsxRZ/ZQSsMpZyLcq8Ea6Ees+j5Oy2A=; b=Kat+WxY11LEE49xbLavuebUwqZfDC4zROYjGTPLDafQ3vikmuAoy0rrMP6Fth4bC8S /fwMtWDmsJghyqog5xmH7pXQt9oCzi2Z5W3tP1FzzuJvvUJkck3rrSSvO8zbFzJg72s5 6YleyN6aCL2qIhcOr0QuSwJIMX53P6UQllUhLeFhezWCMkApG0o9nx1qD8B++hCGy9ju Ftt2eHYUBLEs9KyRdRuqNzFKq6Bn+M3IoBHF2ZklLO7NJ3sIeEqJW5WPOCg+foI/PnFz tWWaGLLzkAZCPrY6AR2VotgGpPt9djtxBBaRGPdYv0C37vJQSlGdefd0TB5kyZgAv2W+ QoPw== X-Forwarded-Encrypted: i=1; AFNElJ9rEC5JjYhRaPnCCtdEVA0H7L5RWNYJwmIWnge82evkenXpeu5bdBqDpWAmBX788G1q/+Rr6YTwa3a0H6g=@vger.kernel.org X-Gm-Message-State: AOJu0Yw/T/RALHfWEWrl5jGlYys/wFHNVTSPYy6+2utguQqPNdqhYdhM 7REtCW+PVSTxd+Yks+kYM8hn/MM4keTpsDKGKBytiCWMnp8qYkCkVIpY X-Gm-Gg: AfdE7cksyNeI1WUkOEDlAOZ0k5LTKmLrXOY7tqKS+f1V/4dfqHeW3TYieo9k/DrnIs7 W8i41pDltBPKd75qL9nrT3iCU94cN8vhZ2uwzKHz8uuytoyZf+4dfStQ5k/+QZKNnkMS1HgiR7f tvmyFSJuClNy8B1RgJB7825mUH5vgMt/W71GXFQkcN53RmFPWjd/Wjtjp+JX4WBOYgGeOD8EZtv CQx67CQ5US2ZeQV61rI5QhqUPGFB7Q0ivpci92NDszjlGVkE29ojkxHZ1SpAyc2bNP4MYDDeqqq cd/oERY4hX2q2qeJoa/ALMb26DzAA/2/huy4GOH1zz86GzZok/w2aouAnP8yk7QX+ueeEjZ4RHn w5QsrhcbZlIIq+aJrAb7HjTGcQTO7EXYR5r73SwSWE40iV7gYQbmi8Wlbx+s+BnJ4+a5JGZyl9o O4yrlf3MZWcZnx3DyHkGUed0EBpAXJsH4eDUYN6Mv/MFH4l1X4ZIG/W7bCnYZt X-Received: by 2002:a17:90b:2e85:b0:368:af5c:5925 with SMTP id 98e67ed59e1d1-37c94b136bdmr5931252a91.23.1781736449387; Wed, 17 Jun 2026 15:47:29 -0700 (PDT) Received: from r912.tailbb6e1e.ts.net ([182.70.116.80]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c8661b5d505sm14890344a12.1.2026.06.17.15.47.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 15:47:28 -0700 (PDT) From: Avinash Duduskar To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org Cc: bpf@vger.kernel.org, davem@davemloft.net, dsahern@kernel.org, eddyz87@gmail.com, edumazet@google.com, emil@etsalapatis.com, horms@kernel.org, john.fastabend@gmail.com, jolsa@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org, martin.lau@linux.dev, memxor@gmail.com, netdev@vger.kernel.org, pabeni@redhat.com, sdf@fomichev.me, song@kernel.org, toke@redhat.com, yonghong.song@linux.dev Subject: [PATCH bpf] bpf: zero-initialize the fib lookup flow struct Date: Thu, 18 Jun 2026 04:17:19 +0530 Message-ID: <20260617224719.1428599-1-avinash.duduskar@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit bpf_ipv4_fib_lookup() and bpf_ipv6_fib_lookup() build the flow key on the stack with a bare "struct flowi4 fl4;" / "struct flowi6 fl6;" and fill it field by field, but never set flowi4_l3mdev / flowi6_l3mdev. On the non-DIRECT path the lookup goes through the fib rules whenever the netns has custom rules, which a VRF installs: bpf_ipv4_fib_lookup() -> fib_lookup() -> __fib_lookup() -> l3mdev_update_flow() reads !fl->flowi_l3mdev -> fib_rules_lookup() -> fib_rule_match() -> l3mdev_fib_rule_match() uses fl->flowi_l3mdev l3mdev_update_flow() resolves the l3mdev master from the ingress device only while the field is still zero. Left at a nonzero stack value the resolution is skipped, and l3mdev_fib_rule_match() then tests that value as an ifindex, so the VRF master is not resolved and the rule fails to match: an ingress enslaved to a VRF can fail to select its table. FIB rules matching on an L3 master device (l3mdev_fib_rule_iif_match()/ _oif_match()) read the same value, so an "ip rule iif/oif " mismatches the same way. Zero-initialize the whole flow struct rather than adding one more field assignment, so any flowi field added later is covered too. ip_route_input_slow() likewise zeroes the field before its input lookup. CONFIG_INIT_STACK_ALL_ZERO masks this by default, but it depends on compiler support (CC_HAS_AUTO_VAR_INIT_ZERO), so INIT_STACK_NONE builds, including older toolchains that fall back to it, are exposed. Built with INIT_STACK_ALL_PATTERN, a plain bpf_fib_lookup (no VLAN, no DIRECT) over a VRF slave whose destination is routed only in the VRF table returns BPF_FIB_LKUP_RET_NOT_FWDED, and resolves with this patch. On the default config the lookup succeeds either way, so ordinary testing does not catch the bug. Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") Signed-off-by: Avinash Duduskar --- net/core/filter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 9590877b0714..7c58df589826 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -6139,7 +6139,7 @@ static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params, struct in_device *in_dev; struct net_device *dev; struct fib_result res; - struct flowi4 fl4; + struct flowi4 fl4 = {}; u32 mtu = 0; int err; @@ -6279,7 +6279,7 @@ static int bpf_ipv6_fib_lookup(struct net *net, struct bpf_fib_lookup *params, struct neighbour *neigh; struct net_device *dev; struct inet6_dev *idev; - struct flowi6 fl6; + struct flowi6 fl6 = {}; int strict = 0; int oif, err; u32 mtu = 0; -- 2.54.0