genetlink misinterprets NEW as GET

12 messages, 4 authors, 2011-01-10 · open the first message on its own page

genetlink misinterprets NEW as GET

From: Jan Engelhardt <hidden>
Date: 2011-01-04 02:14:07

Hey there,


I can't really say whether it's genetlink or netlink to blame,
but I noticed that a request with

	nlmsg_flags = NLM_F_CREATE | NLM_F_EXCL

to a genl-registered component can return -EOPNOTSUPP because it does 
not have a dumpit function defined in struct genl_ops. Make sense?
Not at first sight at least.
include/linux/netlink.h has this nice anecdote:

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)
	
	/* Modifiers to NEW request */
	#define NLM_F_REPLACE   0x100
	#define NLM_F_EXCL      0x200
	#define NLM_F_CREATE    0x400
	#define NLM_F_APPEND    0x800

Except there is nothing that declares a particular Netlink message
as "GET" or "NEW". Subsequently, genetlink chokes:

	if (nlh->nlmsg_flags & NLM_F_DUMP)
		if (ops->dumpit == NULL)
			return -EOPNOTSUPP;

Because NLM_F_CREATE | NLM_F_EXCL == NLM_F_DUMP.
That, of course, is absolutely bogus.

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Re: genetlink misinterprets NEW as GET

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: 2011-01-06 13:48:31

On 04/01/11 03:14, Jan Engelhardt wrote:

Hey there,


I can't really say whether it's genetlink or netlink to blame,
but I noticed that a request with

	nlmsg_flags = NLM_F_CREATE | NLM_F_EXCL

to a genl-registered component can return -EOPNOTSUPP because it does 
not have a dumpit function defined in struct genl_ops. Make sense?
Not at first sight at least.
include/linux/netlink.h has this nice anecdote:

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)
	
	/* Modifiers to NEW request */
	#define NLM_F_REPLACE   0x100
	#define NLM_F_EXCL      0x200
	#define NLM_F_CREATE    0x400
	#define NLM_F_APPEND    0x800

Except there is nothing that declares a particular Netlink message
as "GET" or "NEW". Subsequently, genetlink chokes:

	if (nlh->nlmsg_flags & NLM_F_DUMP)
		if (ops->dumpit == NULL)
			return -EOPNOTSUPP;

Because NLM_F_CREATE | NLM_F_EXCL == NLM_F_DUMP.
That, of course, is absolutely bogus.

Hm, NLM_F_CREATE | NLM_F_EXCL is not equal to NLM_F_DUMP.

You must be hitting -EOPNOTSUPP elsewhere.

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Someone may include NLM_F_ATOMIC to a dump operation, in that case the
checking that you propose is not valid.

Re: genetlink misinterprets NEW as GET

From: Jan Engelhardt <hidden>
Date: 2011-01-06 14:25:29

On Thursday 2011-01-06 14:48, Pablo Neira Ayuso wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)
	
	/* Modifiers to NEW request */
	#define NLM_F_REPLACE   0x100
	#define NLM_F_EXCL      0x200
	#define NLM_F_CREATE    0x400
	#define NLM_F_APPEND    0x800

Except there is nothing that declares a particular Netlink message
as "GET" or "NEW". Subsequently, genetlink chokes:

	if (nlh->nlmsg_flags & NLM_F_DUMP)
		if (ops->dumpit == NULL)
			return -EOPNOTSUPP;

Because NLM_F_CREATE | NLM_F_EXCL == NLM_F_DUMP.
That, of course, is absolutely bogus.

Hm, NLM_F_CREATE | NLM_F_EXCL is not equal to NLM_F_DUMP.

You must be hitting -EOPNOTSUPP elsewhere.

No, I am hitting EOPNOTSUPP here; right it's not equal, sorry.
But nlmsg_flags is tested for NLM_F_MATCH (0x200), which is provided by
NLM_F_EXCL. ipset does use NLM_F_EXCL and thus ran into this.

Re: genetlink misinterprets NEW as GET

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: 2011-01-06 14:55:09

On 06/01/11 15:25, Jan Engelhardt wrote:

On Thursday 2011-01-06 14:48, Pablo Neira Ayuso wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)
	
	/* Modifiers to NEW request */
	#define NLM_F_REPLACE   0x100
	#define NLM_F_EXCL      0x200
	#define NLM_F_CREATE    0x400
	#define NLM_F_APPEND    0x800

Except there is nothing that declares a particular Netlink message
as "GET" or "NEW". Subsequently, genetlink chokes:

	if (nlh->nlmsg_flags & NLM_F_DUMP)
		if (ops->dumpit == NULL)
			return -EOPNOTSUPP;

Because NLM_F_CREATE | NLM_F_EXCL == NLM_F_DUMP.
That, of course, is absolutely bogus.

Hm, NLM_F_CREATE | NLM_F_EXCL is not equal to NLM_F_DUMP.

You must be hitting -EOPNOTSUPP elsewhere.

No, I am hitting EOPNOTSUPP here; right it's not equal, sorry.
But nlmsg_flags is tested for NLM_F_MATCH (0x200), which is provided by
NLM_F_EXCL. ipset does use NLM_F_EXCL and thus ran into this.

i getting confused, so ipset is also setting NLM_F_REPLACE to match the
NLM_F_DUMP bitmask?

Re: genetlink misinterprets NEW as GET

From: Jan Engelhardt <hidden>
Date: 2011-01-06 16:12:59

On Thursday 2011-01-06 15:55, Pablo Neira Ayuso wrote:

On 06/01/11 15:25, Jan Engelhardt wrote:

quoted

On Thursday 2011-01-06 14:48, Pablo Neira Ayuso wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)
	
	/* Modifiers to NEW request */
	#define NLM_F_REPLACE   0x100
	#define NLM_F_EXCL      0x200
	#define NLM_F_CREATE    0x400
	#define NLM_F_APPEND    0x800

i getting confused, so ipset is also setting NLM_F_REPLACE to match the
NLM_F_DUMP bitmask?

Any userspace program sending a (ge)netlink message with
NLM_F_CREATE|NLM_F_EXCL -- with the intent of creating an entry with
excl semantics --, will be misunderstood by genetlink.c to be a dump
request.

The problem is of general nature and not limited to ipset. I only
noticed it while making the ipset-genl patch, because ipset sends all
IPSET_CMD_CREATE requests with
NLM_F_REQUEST|NLM_F_ACK|NLM_F_CREATE|NLM_F_EXCL (see
ipset/lib/mnl.c).

Re: genetlink misinterprets NEW as GET

From: Ben Pfaff <hidden>
Date: 2011-01-06 17:23:57

Pablo Neira Ayuso [off-list ref] writes:

On 04/01/11 03:14, Jan Engelhardt wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)

[...]

quoted

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Someone may include NLM_F_ATOMIC to a dump operation, in that case the
checking that you propose is not valid.

Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
dump operation?  Otherwise the test that Jan proposes looks valid
to me.

Re: genetlink misinterprets NEW as GET

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: 2011-01-07 01:31:25

On 06/01/11 18:23, Ben Pfaff wrote:

Pablo Neira Ayuso [off-list ref] writes:

quoted

On 04/01/11 03:14, Jan Engelhardt wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)

[...]

quoted

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Someone may include NLM_F_ATOMIC to a dump operation, in that case the
checking that you propose is not valid.

Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
dump operation?  Otherwise the test that Jan proposes looks valid
to me.

Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.

Re: genetlink misinterprets NEW as GET

From: Jan Engelhardt <hidden>
Date: 2011-01-07 09:38:49

On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)

[...]

quoted

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Someone may include NLM_F_ATOMIC to a dump operation, in that case the
checking that you propose is not valid.

Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
dump operation?  Otherwise the test that Jan proposes looks valid
to me.

Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.

But that would still mean that a user sending a
NLM_F_REQUEST|NLM_F_REPLACE|NLM_F_EXCL message would be misinterpreted
as NLM_F_DUMP.
There just is no way for genl to figure out from an arbitrary nlmsghdr
whether it's a dump request or something else without breaking 
something.
The overlapping of NLM_F_ is quite unfortunate.

Re: genetlink misinterprets NEW as GET

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: 2011-01-07 12:12:25

On 07/01/11 10:38, Jan Engelhardt wrote:

On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)

[...]

quoted

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Someone may include NLM_F_ATOMIC to a dump operation, in that case the
checking that you propose is not valid.

Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
dump operation?  Otherwise the test that Jan proposes looks valid
to me.

Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.

But that would still mean that a user sending a
NLM_F_REQUEST|NLM_F_REPLACE|NLM_F_EXCL message would be misinterpreted
as NLM_F_DUMP.

That flag combination does not make sense to me. Valid combinations are:

NLM_F_REQUEST|NLM_F_CREATE : if it does not exist, create it, if it
exists, update it.
NLM_F_REQUEST|NLM_F_CREATE|NLM_F_EXCL: if it does not exist, create it,
if it exists, return -EEXIST.
NLM_F_REQUEST|NLM_F_REPLACE: if it does not exist, return -ENOENT, if it
exists, replace it.

[patch] Re: genetlink misinterprets NEW as GET

From: Jan Engelhardt <hidden>
Date: 2011-01-07 13:15:05

On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote:

quoted

On 04/01/11 03:14, Jan Engelhardt wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)

[...]

quoted

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Someone may include NLM_F_ATOMIC to a dump operation, in that case the
checking that you propose is not valid.

Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
dump operation?  Otherwise the test that Jan proposes looks valid
to me.

Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.

Turns out genetlink isn't the only place where &NLM_F_DUMP is used 
without ==NLM_F_DUMP.
Thus I am adding it to other spots in net/ too.



parent c235848c5a76520b90cf31bfbcc17720b24745a2 (v2.6.37-rc1-230-gc235848)
commit eaab9042b29931730d6785bb3f27b174fb2f5518
Author: Jan Engelhardt [off-list ref]
Date:   Fri Jan 7 13:53:49 2011 +0100

netlink: test for all flags of the NLM_F_DUMP composite

Due to NLM_F_DUMP is composed of two bits, NLM_F_ROOT | NLM_F_MATCH,
when doing "if (x & NLM_F_DUMP)", it tests for _either_ of the bits
being set. Because NLM_F_MATCH's value overlaps with NLM_F_EXCL,
non-dump requests with NLM_F_EXCL set are mistaken as dump requests.

Substitute the condition to test for _all_ bits being set.

Signed-off-by: Jan Engelhardt <redacted>
---
 net/core/rtnetlink.c                 |    2 +-
 net/ipv4/inet_diag.c                 |    2 +-
 net/netfilter/nf_conntrack_netlink.c |    4 ++--
 net/netlink/genetlink.c              |    2 +-
 net/xfrm/xfrm_user.c                 |    2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 8121268..14dcb43 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c

@@ -1657,7 +1657,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
 	if (kind != 2 && security_netlink_recv(skb, CAP_NET_ADMIN))
 		return -EPERM;
 
-	if (kind == 2 && nlh->nlmsg_flags&NLM_F_DUMP) {
+	if (kind == 2 && (nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
 		struct sock *rtnl;
 		rtnl_dumpit_func dumpit;

diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index 2ada171..2746c1f 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c

@@ -858,7 +858,7 @@ static int inet_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
 	    nlmsg_len(nlh) < hdrlen)
 		return -EINVAL;
 
-	if (nlh->nlmsg_flags & NLM_F_DUMP) {
+	if ((nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
 		if (nlmsg_attrlen(nlh, hdrlen)) {
 			struct nlattr *attr;

diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 7f59be8..edc737e 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c

@@ -925,7 +925,7 @@ ctnetlink_get_conntrack(struct sock *ctnl, struct sk_buff *skb,
 	u16 zone;
 	int err;
 
-	if (nlh->nlmsg_flags & NLM_F_DUMP)
+	if ((nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP)
 		return netlink_dump_start(ctnl, skb, nlh, ctnetlink_dump_table,
 					  ctnetlink_done);

@@ -1788,7 +1788,7 @@ ctnetlink_get_expect(struct sock *ctnl, struct sk_buff *skb,
 	u16 zone;
 	int err;
 
-	if (nlh->nlmsg_flags & NLM_F_DUMP) {
+	if ((nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
 		return netlink_dump_start(ctnl, skb, nlh,
 					  ctnetlink_exp_dump_table,
 					  ctnetlink_exp_done);

diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 1781d99..f83cb37 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c

@@ -519,7 +519,7 @@ static int genl_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
 	    security_netlink_recv(skb, CAP_NET_ADMIN))
 		return -EPERM;
 
-	if (nlh->nlmsg_flags & NLM_F_DUMP) {
+	if ((nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
 		if (ops->dumpit == NULL)
 			return -EOPNOTSUPP;

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 8bae6b2..6770895 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c

@@ -2174,7 +2174,7 @@ static int xfrm_user_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
 
 	if ((type == (XFRM_MSG_GETSA - XFRM_MSG_BASE) ||
 	     type == (XFRM_MSG_GETPOLICY - XFRM_MSG_BASE)) &&
-	    (nlh->nlmsg_flags & NLM_F_DUMP)) {
+	    (nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
 		if (link->dump == NULL)
 			return -EINVAL;

-- 
# Created with git-export-patch

Re: [patch] Re: genetlink misinterprets NEW as GET

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: 2011-01-07 13:33:08

On 07/01/11 14:15, Jan Engelhardt wrote:

On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote:

quoted

On 04/01/11 03:14, Jan Engelhardt wrote:

quoted

	/* Modifiers to GET request */
	#define NLM_F_ROOT      0x100
	#define NLM_F_MATCH     0x200
	#define NLM_F_ATOMIC    0x400
	#define NLM_F_DUMP      (NLM_F_ROOT|NLM_F_MATCH)

[...]

quoted

[N.B.: I am also wondering whether
	(nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
may have been desired, because NLM_F_DUMP is composed of two bits.]

Someone may include NLM_F_ATOMIC to a dump operation, in that case the
checking that you propose is not valid.

Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
dump operation?  Otherwise the test that Jan proposes looks valid
to me.

Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.

Turns out genetlink isn't the only place where &NLM_F_DUMP is used 
without ==NLM_F_DUMP.
Thus I am adding it to other spots in net/ too.



parent c235848c5a76520b90cf31bfbcc17720b24745a2 (v2.6.37-rc1-230-gc235848)
commit eaab9042b29931730d6785bb3f27b174fb2f5518
Author: Jan Engelhardt [off-list ref]
Date:   Fri Jan 7 13:53:49 2011 +0100

netlink: test for all flags of the NLM_F_DUMP composite

Due to NLM_F_DUMP is composed of two bits, NLM_F_ROOT | NLM_F_MATCH,
when doing "if (x & NLM_F_DUMP)", it tests for _either_ of the bits
being set. Because NLM_F_MATCH's value overlaps with NLM_F_EXCL,
non-dump requests with NLM_F_EXCL set are mistaken as dump requests.

Substitute the condition to test for _all_ bits being set.

Signed-off-by: Jan Engelhardt <redacted>

Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>

Re: [patch] Re: genetlink misinterprets NEW as GET

From: David Miller <davem@davemloft.net>
Date: 2011-01-10 00:25:33

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 07 Jan 2011 14:33:08 +0100

On 07/01/11 14:15, Jan Engelhardt wrote:

quoted

netlink: test for all flags of the NLM_F_DUMP composite

Due to NLM_F_DUMP is composed of two bits, NLM_F_ROOT | NLM_F_MATCH,
when doing "if (x & NLM_F_DUMP)", it tests for _either_ of the bits
being set. Because NLM_F_MATCH's value overlaps with NLM_F_EXCL,
non-dump requests with NLM_F_EXCL set are mistaken as dump requests.

Substitute the condition to test for _all_ bits being set.

Signed-off-by: Jan Engelhardt <redacted>

Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>

Applied, and queued up for -stable, thanks guys!

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help