Skip to contentSkip to conversation

Patch "ipv4: initialize flowi4_flags before calling fib_lookup()" has been added to the 4.5-stable tree

PATCH [email protected] 1 participant 1 message Apr 16, 2016

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

ipv4: initialize flowi4_flags before calling fib_lookup()

to the 4.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
ipv4-initialize-flowi4_flags-before-calling-fib_lookup.patch
and it can be found in the queue-4.5 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Sat Apr 16 09:15:18 PDT 2016

From: Lance Richardson <[email protected]>
Date: Tue, 22 Mar 2016 14:56:57 -0400
Subject: ipv4: initialize flowi4_flags before calling fib_lookup()

From: Lance Richardson <[email protected]>

[ Upstream commit 4cfc86f3dae6ca38ed49cdd78f458a03d4d87992 ]

Field fl4.flowi4_flags is not initialized in fib_compute_spec_dst() before calling fib_lookup(), which means fib_table_lookup() is using non-deterministic data at this line:

	if (!(flp->flowi4_flags & FLOWI_FLAG_SKIP_NH_OIF)) {

Fix by initializing the entire fl4 structure, which will prevent similar issues as fields are added in the future by ensuring that all fields are initialized to zero unless explicitly initialized to another value.

Fixes 58189ca7b2741 ("net: Fix vti use case with oif in dst lookups")
---
 net/ipv4/fib_frontend.c |   16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)
net/ipv4/fib_frontend.c +7 -9
@@ -280,7 +280,6 @@ __be32 fib_compute_spec_dst(struct sk_bu
 	struct in_device *in_dev;
 	struct fib_result res;
 	struct rtable *rt;
-	struct flowi4 fl4;
 	struct net *net;
 	int scope;
 
@@ -296,14 +295,13 @@ __be32 fib_compute_spec_dst(struct sk_bu
 
 	scope = RT_SCOPE_UNIVERSE;
 	if (!ipv4_is_zeronet(ip_hdr(skb)->saddr)) {
-		fl4.flowi4_oif = 0;
-		fl4.flowi4_iif = LOOPBACK_IFINDEX;
-		fl4.daddr = ip_hdr(skb)->saddr;
-		fl4.saddr = 0;
-		fl4.flowi4_tos = RT_TOS(ip_hdr(skb)->tos);
-		fl4.flowi4_scope = scope;
-		fl4.flowi4_mark = IN_DEV_SRC_VMARK(in_dev) ? skb->mark : 0;
-		fl4.flowi4_tun_key.tun_id = 0;
+		struct flowi4 fl4 = {
+			.flowi4_iif = LOOPBACK_IFINDEX,
+			.daddr = ip_hdr(skb)->saddr,
+			.flowi4_tos = RT_TOS(ip_hdr(skb)->tos),
+			.flowi4_scope = scope,
+			.flowi4_mark = IN_DEV_SRC_VMARK(in_dev) ? skb->mark : 0,
+		};
 		if (!fib_lookup(net, &fl4, &res, 0))
 			return FIB_RES_PREFSRC(net, res);
 	} else {

Patches currently in stable-queue which might be from [email protected] are

queue-4.5/ipv4-initialize-flowi4_flags-before-calling-fib_lookup.patch