| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1324778255-2830-8-git-send-email-pablo@netfilter.org> Date: Sun, 25 Dec 2011 02:57:23 +0100 From: pablo@...filter.org To: netfilter-devel@...r.kernel.org Cc: davem@...emloft.net, netdev@...r.kernel.org Subject: [PATCH 07/19] netfilter: ctnetlink: use expect instead of master tuple in get operation From: Pablo Neira Ayuso <pablo@...filter.org> Use the expect tuple (if possible) instead of the master tuple for the get operation. If two or more expectations come from the same master, the returned expectation may not be the one that user-space is requesting. This is how it works for the expect deletion operation. Although I think that nobody has been seriously using this. We accept both possibilities, using the expect tuple if possible. I decided to do it like this to avoid breaking backward compatibility. Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org> --- net/netfilter/nf_conntrack_netlink.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index a36e655..77d209c 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -1851,7 +1851,9 @@ ctnetlink_get_expect(struct sock *ctnl, struct sk_buff *skb, if (err < 0) return err; - if (cda[CTA_EXPECT_MASTER]) + if (cda[CTA_EXPECT_TUPLE]) + err = ctnetlink_parse_tuple(cda, &tuple, CTA_EXPECT_TUPLE, u3); + else if (cda[CTA_EXPECT_MASTER]) err = ctnetlink_parse_tuple(cda, &tuple, CTA_EXPECT_MASTER, u3); else return -EINVAL; -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists