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@xxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
