* genetlink misinterprets NEW as GET @ 2011-01-04 2:14 Jan Engelhardt 2011-01-06 13:48 ` Pablo Neira Ayuso 0 siblings, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2011-01-04 2:14 UTC (permalink / raw) To: Netfilter Developer Mailing List; +Cc: Linux Networking Developer Mailing List 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.] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-04 2:14 genetlink misinterprets NEW as GET Jan Engelhardt @ 2011-01-06 13:48 ` Pablo Neira Ayuso 2011-01-06 14:25 ` Jan Engelhardt 2011-01-06 17:23 ` Ben Pfaff 0 siblings, 2 replies; 12+ messages in thread From: Pablo Neira Ayuso @ 2011-01-06 13:48 UTC (permalink / raw) To: Jan Engelhardt Cc: Netfilter Developer Mailing List, Linux Networking Developer Mailing List 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-06 13:48 ` Pablo Neira Ayuso @ 2011-01-06 14:25 ` Jan Engelhardt 2011-01-06 14:55 ` Pablo Neira Ayuso 2011-01-06 17:23 ` Ben Pfaff 1 sibling, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2011-01-06 14:25 UTC (permalink / raw) To: Pablo Neira Ayuso Cc: Netfilter Developer Mailing List, Linux Networking Developer Mailing List On Thursday 2011-01-06 14:48, Pablo Neira Ayuso wrote: >> >> /* 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-06 14:25 ` Jan Engelhardt @ 2011-01-06 14:55 ` Pablo Neira Ayuso 2011-01-06 16:12 ` Jan Engelhardt 0 siblings, 1 reply; 12+ messages in thread From: Pablo Neira Ayuso @ 2011-01-06 14:55 UTC (permalink / raw) To: Jan Engelhardt Cc: Netfilter Developer Mailing List, Linux Networking Developer Mailing List On 06/01/11 15:25, Jan Engelhardt wrote: > On Thursday 2011-01-06 14:48, Pablo Neira Ayuso wrote: >>> >>> /* 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-06 14:55 ` Pablo Neira Ayuso @ 2011-01-06 16:12 ` Jan Engelhardt 0 siblings, 0 replies; 12+ messages in thread From: Jan Engelhardt @ 2011-01-06 16:12 UTC (permalink / raw) To: Pablo Neira Ayuso Cc: Netfilter Developer Mailing List, Linux Networking Developer Mailing List On Thursday 2011-01-06 15:55, Pablo Neira Ayuso wrote: >On 06/01/11 15:25, Jan Engelhardt wrote: >> On Thursday 2011-01-06 14:48, Pablo Neira Ayuso wrote: >>>> >>>> /* 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-06 13:48 ` Pablo Neira Ayuso 2011-01-06 14:25 ` Jan Engelhardt @ 2011-01-06 17:23 ` Ben Pfaff 2011-01-07 1:31 ` Pablo Neira Ayuso 1 sibling, 1 reply; 12+ messages in thread From: Ben Pfaff @ 2011-01-06 17:23 UTC (permalink / raw) To: Pablo Neira Ayuso Cc: Jan Engelhardt, Netfilter Developer Mailing List, Linux Networking Developer Mailing List Pablo Neira Ayuso <pablo@netfilter.org> writes: > On 04/01/11 03:14, Jan Engelhardt wrote: >> /* 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) [...] >> [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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-06 17:23 ` Ben Pfaff @ 2011-01-07 1:31 ` Pablo Neira Ayuso 2011-01-07 9:38 ` Jan Engelhardt 2011-01-07 13:15 ` [patch] " Jan Engelhardt 0 siblings, 2 replies; 12+ messages in thread From: Pablo Neira Ayuso @ 2011-01-07 1:31 UTC (permalink / raw) To: Ben Pfaff Cc: Jan Engelhardt, Netfilter Developer Mailing List, Linux Networking Developer Mailing List On 06/01/11 18:23, Ben Pfaff wrote: > Pablo Neira Ayuso <pablo@netfilter.org> writes: > >> On 04/01/11 03:14, Jan Engelhardt wrote: >>> /* 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) > [...] >>> [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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-07 1:31 ` Pablo Neira Ayuso @ 2011-01-07 9:38 ` Jan Engelhardt 2011-01-07 12:12 ` Pablo Neira Ayuso 2011-01-07 13:15 ` [patch] " Jan Engelhardt 1 sibling, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2011-01-07 9:38 UTC (permalink / raw) To: Pablo Neira Ayuso Cc: Ben Pfaff, Netfilter Developer Mailing List, Linux Networking Developer Mailing List On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote: >>>> /* 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) >> [...] >>>> [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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: genetlink misinterprets NEW as GET 2011-01-07 9:38 ` Jan Engelhardt @ 2011-01-07 12:12 ` Pablo Neira Ayuso 0 siblings, 0 replies; 12+ messages in thread From: Pablo Neira Ayuso @ 2011-01-07 12:12 UTC (permalink / raw) To: Jan Engelhardt Cc: Ben Pfaff, Netfilter Developer Mailing List, Linux Networking Developer Mailing List On 07/01/11 10:38, Jan Engelhardt wrote: > > On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote: >>>>> /* 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) >>> [...] >>>>> [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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [patch] Re: genetlink misinterprets NEW as GET 2011-01-07 1:31 ` Pablo Neira Ayuso 2011-01-07 9:38 ` Jan Engelhardt @ 2011-01-07 13:15 ` Jan Engelhardt 2011-01-07 13:33 ` Pablo Neira Ayuso 1 sibling, 1 reply; 12+ messages in thread From: Jan Engelhardt @ 2011-01-07 13:15 UTC (permalink / raw) To: David S. Miller Cc: Pablo Neira Aysuo, Ben Pfaff, Netfilter Developer Mailing List, Linux Networking Developer Mailing List On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote: >>> On 04/01/11 03:14, Jan Engelhardt wrote: >>>> /* 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) >> [...] >>>> [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 <jengelh@medozas.de> 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 <jengelh@medozas.de> --- 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [patch] Re: genetlink misinterprets NEW as GET 2011-01-07 13:15 ` [patch] " Jan Engelhardt @ 2011-01-07 13:33 ` Pablo Neira Ayuso 2011-01-10 0:25 ` David Miller 0 siblings, 1 reply; 12+ messages in thread From: Pablo Neira Ayuso @ 2011-01-07 13:33 UTC (permalink / raw) To: Jan Engelhardt Cc: David S. Miller, Ben Pfaff, Netfilter Developer Mailing List, Linux Networking Developer Mailing List On 07/01/11 14:15, Jan Engelhardt wrote: > On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote: >>>> On 04/01/11 03:14, Jan Engelhardt wrote: >>>>> /* 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) >>> [...] >>>>> [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 <jengelh@medozas.de> > 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 <jengelh@medozas.de> Acked-by: Pablo Neira Ayuso <pablo@netfilter.org> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch] Re: genetlink misinterprets NEW as GET 2011-01-07 13:33 ` Pablo Neira Ayuso @ 2011-01-10 0:25 ` David Miller 0 siblings, 0 replies; 12+ messages in thread From: David Miller @ 2011-01-10 0:25 UTC (permalink / raw) To: pablo; +Cc: jengelh, blp, netfilter-devel, netdev 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: >> 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 <jengelh@medozas.de> > > Acked-by: Pablo Neira Ayuso <pablo@netfilter.org> Applied, and queued up for -stable, thanks guys! ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-01-10 0:25 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-04 2:14 genetlink misinterprets NEW as GET Jan Engelhardt 2011-01-06 13:48 ` Pablo Neira Ayuso 2011-01-06 14:25 ` Jan Engelhardt 2011-01-06 14:55 ` Pablo Neira Ayuso 2011-01-06 16:12 ` Jan Engelhardt 2011-01-06 17:23 ` Ben Pfaff 2011-01-07 1:31 ` Pablo Neira Ayuso 2011-01-07 9:38 ` Jan Engelhardt 2011-01-07 12:12 ` Pablo Neira Ayuso 2011-01-07 13:15 ` [patch] " Jan Engelhardt 2011-01-07 13:33 ` Pablo Neira Ayuso 2011-01-10 0:25 ` David Miller
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).