netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Álvaro Neira Ayuso" <alvaroneay@gmail.com>
Cc: netfilter-devel@vger.kernel.org, kaber@trash.net
Subject: Re: [nft PATCH 1/4 v2] evaluate: fix a crash if we specify ether type or meta nfproto in reject
Date: Fri, 17 Oct 2014 15:38:17 +0200	[thread overview]
Message-ID: <20141017133817.GA4163@salvia> (raw)
In-Reply-To: <5441134F.6020104@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Fri, Oct 17, 2014 at 03:02:07PM +0200, Álvaro Neira Ayuso wrote:
> El 17/10/14 14:55, Pablo Neira Ayuso escribió:
> >On Fri, Oct 17, 2014 at 02:24:34PM +0200, Alvaro Neira Ayuso wrote:
> >>If we use a rule:
> >>nft add rule bridge filter input \
> >>	ether type ip reject with icmp type host-unreachable
> >>
> >>or this:
> >>
> >>nft add rule inet filter input \
> >>	meta nfproto ipv4 reject with icmp type host-unreachable
> >>
> >>we have a segfault because we add a network dependency when we already have
> >>network context.
> >>
> >>Signed-off-by: Alvaro Neira Ayuso <alvaroneay@gmail.com>
> >>---
> >>[changes in v2]
> >>* Fixed a incorrect refactor when we check the family in bridge
> >>
> >>  src/evaluate.c |   57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> >>  1 file changed, 56 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/src/evaluate.c b/src/evaluate.c
> >>index 83ef749..4b7bda9 100644
> >>--- a/src/evaluate.c
> >>+++ b/src/evaluate.c
> >>@@ -19,6 +19,7 @@
> >>  #include <linux/netfilter/nf_tables.h>
> >>  #include <netinet/ip_icmp.h>
> >>  #include <netinet/icmp6.h>
> >>+#include <net/ethernet.h>
> >>
> >>  #include <expression.h>
> >>  #include <statement.h>
> >>@@ -1193,6 +1194,8 @@ static int stmt_reject_gen_dependency(struct eval_ctx *ctx, struct stmt *stmt,
> >>  		BUG("cannot generate reject dependency for type %d",
> >>  		    stmt->reject.type);
> >>  	}
> >>+	if (payload == NULL)
> >>+		return 0;
> >
> >Why this check?
> 
> If we already have context, the previously functions return a NULL
> payload. Therefore, if we try to create a dependency with this NULL
> payload, we have a crash.

I prefer if you can change the return value logic in
reject_payload_gen_dependency*() to:

  1: payload dependency was created
  0: no payload dependency needed
 -1: error

See patch attached.

[-- Attachment #2: x.patch --]
[-- Type: text/x-diff, Size: 1531 bytes --]

diff --git a/src/evaluate.c b/src/evaluate.c
index d61d76b..71dc767 100644
--- a/src/evaluate.c
+++ b/src/evaluate.c
@@ -1140,9 +1140,10 @@ static int reject_payload_gen_dependency_tcp(struct eval_ctx *ctx,
 	desc = ctx->pctx.protocol[PROTO_BASE_TRANSPORT_HDR].desc;
 	if (desc != NULL)
 		return 0;
+
 	*payload = payload_expr_alloc(&stmt->location, &proto_tcp,
 				      TCPHDR_UNSPEC);
-	return 0;
+	return 1;
 }
 
 static int reject_payload_gen_dependency_family(struct eval_ctx *ctx,
@@ -1171,7 +1172,7 @@ static int reject_payload_gen_dependency_family(struct eval_ctx *ctx,
 	default:
 		BUG("unknown reject family");
 	}
-	return 0;
+	return 1;
 }
 
 static int stmt_reject_gen_dependency(struct eval_ctx *ctx, struct stmt *stmt,
@@ -1179,21 +1180,21 @@ static int stmt_reject_gen_dependency(struct eval_ctx *ctx, struct stmt *stmt,
 {
 	struct expr *payload = NULL;
 	struct stmt *nstmt;
+	int ret;
 
 	switch (stmt->reject.type) {
 	case NFT_REJECT_TCP_RST:
-		if (reject_payload_gen_dependency_tcp(ctx, stmt, &payload) < 0)
-			return -1;
+		ret = reject_payload_gen_dependency_tcp(ctx, stmt, &payload);
 		break;
 	case NFT_REJECT_ICMP_UNREACH:
-		if (reject_payload_gen_dependency_family(ctx, stmt,
-							 &payload) < 0)
-			return -1;
+		ret = reject_payload_gen_dependency_family(ctx, stmt, &payload);
 		break;
 	default:
 		BUG("cannot generate reject dependency for type %d",
 		    stmt->reject.type);
 	}
+	if (ret <= 0)
+		return ret;
 
 	if (payload_gen_dependency(ctx, payload, &nstmt) < 0)
 		return -1;

  reply	other threads:[~2014-10-17 13:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17 12:24 [nft PATCH 1/4 v2] evaluate: fix a crash if we specify ether type or meta nfproto in reject Alvaro Neira Ayuso
2014-10-17 12:24 ` [nft PATCH 2/4 v2] evaluate: fix a crash if we check the transport protocol Alvaro Neira Ayuso
2014-10-20  8:59   ` Pablo Neira Ayuso
2014-10-20  9:40     ` Álvaro Neira Ayuso
2014-10-20  9:46       ` Pablo Neira Ayuso
2014-10-20  9:50         ` Álvaro Neira Ayuso
2014-10-17 12:24 ` [nft PATCH 3/4 v2] delinearize: list the icmpx reason with the string associated Alvaro Neira Ayuso
2014-10-17 12:58   ` Pablo Neira Ayuso
2014-10-17 12:24 ` [nft PATCH 4/4 v2] test: update and add the reject tests for ip, ip6, bridge and inet Alvaro Neira Ayuso
2014-10-17 12:55 ` [nft PATCH 1/4 v2] evaluate: fix a crash if we specify ether type or meta nfproto in reject Pablo Neira Ayuso
2014-10-17 13:02   ` Álvaro Neira Ayuso
2014-10-17 13:38     ` Pablo Neira Ayuso [this message]
2014-10-17 13:44       ` Álvaro Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141017133817.GA4163@salvia \
    --to=pablo@netfilter.org \
    --cc=alvaroneay@gmail.com \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).