Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1517172 > unrolled thread

[PATCH 2/2] [nf-next] netfilter: fix NF_REPEAT handling

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/2] [nf-next] netfilter: fix NF_REPEAT handling Arnd Bergmann <arnd@arndb.de> - 2016-11-08 14:40 +0100
    Re: [PATCH 2/2] [nf-next] netfilter: fix NF_REPEAT handling Pablo Neira Ayuso <pablo@netfilter.org> - 2016-11-10 00:20 +0100

#1517172 — [PATCH 2/2] [nf-next] netfilter: fix NF_REPEAT handling

gcc correctly identified a theoretical uninitialized variable use:

net/netfilter/nf_conntrack_core.c: In function 'nf_conntrack_in':
net/netfilter/nf_conntrack_core.c:1125:14: error: 'l4proto' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This could only happen when we 'goto out' before looking up l4proto,
and then enter the retry, implying that l3proto->get_l4proto()
returned NF_REPEAT. This does not currently get returned in any
code path and probably won't ever happen, but is not good to
rely on.

Moving the repeat handling up a little should have the same
behavior as today but avoids the warning by making that case
impossible to enter.

Fixes: 08733a0cb7de ("netfilter: handle NF_REPEAT from nf_conntrack_in()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The patch causing this is currently only in nf-next, and not yet
in net-next.
---
 net/netfilter/nf_conntrack_core.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index de4b8a75f30b..610c9de0ce18 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1337,6 +1337,8 @@ nf_conntrack_in(struct net *net, u_int8_t pf, unsigned int hooknum,
 		NF_CT_STAT_INC_ATOMIC(net, invalid);
 		if (ret == -NF_DROP)
 			NF_CT_STAT_INC_ATOMIC(net, drop);
+		if (ret == -NF_REPEAT && tmpl)
+			goto repeat;
 		ret = -ret;
 		goto out;
 	}
@@ -1349,10 +1351,7 @@ nf_conntrack_in(struct net *net, u_int8_t pf, unsigned int hooknum,
 		 * closed/aborted connection. We have to go back and create a
 		 * fresh conntrack.
 		 */
-		if (ret == NF_REPEAT)
-			goto repeat;
-		else
-			nf_ct_put(tmpl);
+		nf_ct_put(tmpl);
 	}
 
 	return ret;
-- 
2.9.0

[toc] | [next] | [standalone]

#1518560

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 08, 2016 at 02:28:19PM +0100, Arnd Bergmann wrote:
> gcc correctly identified a theoretical uninitialized variable use:
> 
> net/netfilter/nf_conntrack_core.c: In function 'nf_conntrack_in':
> net/netfilter/nf_conntrack_core.c:1125:14: error: 'l4proto' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This could only happen when we 'goto out' before looking up l4proto,
> and then enter the retry, implying that l3proto->get_l4proto()
> returned NF_REPEAT. This does not currently get returned in any
> code path and probably won't ever happen, but is not good to
> rely on.
> 
> Moving the repeat handling up a little should have the same
> behavior as today but avoids the warning by making that case
> impossible to enter.
> 
> Fixes: 08733a0cb7de ("netfilter: handle NF_REPEAT from nf_conntrack_in()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> The patch causing this is currently only in nf-next, and not yet
> in net-next.
> ---
>  net/netfilter/nf_conntrack_core.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index de4b8a75f30b..610c9de0ce18 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1337,6 +1337,8 @@ nf_conntrack_in(struct net *net, u_int8_t pf, unsigned int hooknum,
>  		NF_CT_STAT_INC_ATOMIC(net, invalid);
>  		if (ret == -NF_DROP)
>  			NF_CT_STAT_INC_ATOMIC(net, drop);
> +		if (ret == -NF_REPEAT && tmpl)
> +			goto repeat;

This is my fault, I'm going to mangle this patch since 08733a0cb7de
really broke the NF_REPEAT handling. We should inconditionally jump
back to repeat if we get NF_REPEAT, no matter if the template is set
or not. I'll include a side node on this mangling.

>  		ret = -ret;
>  		goto out;
>  	}
> @@ -1349,10 +1351,7 @@ nf_conntrack_in(struct net *net, u_int8_t pf, unsigned int hooknum,
>  		 * closed/aborted connection. We have to go back and create a
>  		 * fresh conntrack.
>  		 */

I'm going to move the comment above on top of the NF_REPEAT check, so
it still keeps around as context.

BTW, the revamped patch looks like the one attached.

Thanks a lot for addressing this fallout.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web