[libnetfilter_conntrack PATCH] conntrack: increase the length of `l4proto_map`

[libnetfilter_conntrack PATCH] conntrack: increase the length of `l4proto_map`

[Jeremy Sowden]

With addition of MPTCP `IPPROTO_MAX` is greater than 256, so extend the
array to account for the new upper bound.

Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
---
 include/internal/object.h | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/internal/object.h b/include/internal/object.h
index 75ffdbe97229..b919f5784df3 100644
--- a/include/internal/object.h
+++ b/include/internal/object.h
@@ -6,6 +6,7 @@
 #ifndef _NFCT_OBJECT_H_
 #define _NFCT_OBJECT_H_
 
+#include <internal/bitops.h>
 #include <libnetfilter_conntrack/libnetfilter_conntrack.h>
 
 /*
@@ -223,12 +224,13 @@ struct nfct_filter {
 	enum nfct_filter_logic 	logic[NFCT_FILTER_MAX];
 
 	/*
-	 * This the layer 4 protocol map for filtering. Not more than 
-	 * 255 protocols (maximum is IPPROTO_MAX which is 256). Actually,
-	 * I doubt that anyone can reach such a limit.
+	 * This the layer 4 protocol map for filtering. Not more than 255
+	 * protocols.  Although IPPROTO_MAX is currently 263, there are many
+	 * fewer protocols defined in netinet/in.h, so no one should reach this
+	 * limit.
 	 */
 #define __FILTER_L4PROTO_MAX	255
-	uint32_t 		l4proto_map[IPPROTO_MAX/32];
+	uint32_t 		l4proto_map[DIV_ROUND_UP(IPPROTO_MAX, 32)];
 	uint32_t		l4proto_len;
 
 	struct {
-- 
2.35.1

Re: [libnetfilter_conntrack PATCH] conntrack: increase the length of `l4proto_map`

[Pablo Neira Ayuso]

On Fri, Dec 23, 2022 at 12:38:06PM +0000, Jeremy Sowden wrote:
> With addition of MPTCP `IPPROTO_MAX` is greater than 256, so extend the
> array to account for the new upper bound.

Applied, thanks.

I don't expect we will ever see IPPROTO_MPTCP in this path though.
To my understanding, this definition is targeted at the
setsockopt/getsockopt() use-case. IP headers and the ctnetlink
interface also assumes 8-bits protocol numbers.

Re: [libnetfilter_conntrack PATCH] conntrack: increase the length of `l4proto_map`

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Fri, Dec 23, 2022 at 12:38:06PM +0000, Jeremy Sowden wrote:
> > With addition of MPTCP `IPPROTO_MAX` is greater than 256, so extend the
> > array to account for the new upper bound.
> 
> Applied, thanks.
> 
> I don't expect we will ever see IPPROTO_MPTCP in this path though.
> To my understanding, this definition is targeted at the
> setsockopt/getsockopt() use-case. IP headers and the ctnetlink
> interface also assumes 8-bits protocol numbers.

Yes, this is an uapi thing:

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); vs.
socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);

Only second version results in a multipath-tcp aware socket.

If mptcp is active (both peers need to support it), tcp frames will
have an 'mptcp' option, but its still tcp (6) on wire.

Re: [libnetfilter_conntrack PATCH] conntrack: increase the length of `l4proto_map`

[Pablo Neira Ayuso]

On Wed, Jan 11, 2023 at 07:08:18PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Fri, Dec 23, 2022 at 12:38:06PM +0000, Jeremy Sowden wrote:
> > > With addition of MPTCP `IPPROTO_MAX` is greater than 256, so extend the
> > > array to account for the new upper bound.
> > 
> > Applied, thanks.
> > 
> > I don't expect we will ever see IPPROTO_MPTCP in this path though.
> > To my understanding, this definition is targeted at the
> > setsockopt/getsockopt() use-case. IP headers and the ctnetlink
> > interface also assumes 8-bits protocol numbers.
> 
> Yes, this is an uapi thing:
> 
> socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); vs.
> socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);
> 
> Only second version results in a multipath-tcp aware socket.
> 
> If mptcp is active (both peers need to support it), tcp frames will
> have an 'mptcp' option, but its still tcp (6) on wire.

Thanks for confirming.

Probably I'll post a patch to add an internal __IPPROTO_MAX definition
that sticks to 255, so libnetfilter_conntrack maps don't start
increasing if more IPPROTO_* definitions show up in the future for the
setsockopt/getsockopt interface.

Re: [libnetfilter_conntrack PATCH] conntrack: increase the length of `l4proto_map`

[Jeremy Sowden]

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

On 2023-01-11, at 19:21:09 +0100, Pablo Neira Ayuso wrote:
> On Wed, Jan 11, 2023 at 07:08:18PM +0100, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > On Fri, Dec 23, 2022 at 12:38:06PM +0000, Jeremy Sowden wrote:
> > > > With addition of MPTCP `IPPROTO_MAX` is greater than 256, so extend the
> > > > array to account for the new upper bound.
> > > 
> > > Applied, thanks.
> > > 
> > > I don't expect we will ever see IPPROTO_MPTCP in this path though.
> > > To my understanding, this definition is targeted at the
> > > setsockopt/getsockopt() use-case. IP headers and the ctnetlink
> > > interface also assumes 8-bits protocol numbers.
> > 
> > Yes, this is an uapi thing:
> > 
> > socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); vs.
> > socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);
> > 
> > Only second version results in a multipath-tcp aware socket.
> > 
> > If mptcp is active (both peers need to support it), tcp frames will
> > have an 'mptcp' option, but its still tcp (6) on wire.
> 
> Thanks for confirming.
> 
> Probably I'll post a patch to add an internal __IPPROTO_MAX definition
> that sticks to 255, so libnetfilter_conntrack maps don't start
> increasing if more IPPROTO_* definitions show up in the future for the
> setsockopt/getsockopt interface.
> 

Fbm.

Just to be clear, the problem I wanted to fix (why I didn't put this
in the commit message I don't know) was this from bsf.c (ll. 473ff.):

        for (i = 0; i < IPPROTO_MAX; i++) {
                if (test_bit(i, f->l4proto_map)) {
                        j += nfct_bsf_cmp_k_stack(this, i, jt - j, j, s);
                }
        }

where we are currently reading past the end of array.

J.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]