netdev - Re: IP oversized ip oacket from - header size should be skipped?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA85sZt1kX6RdmCsEiUabpV0-y_O3a0yku6H7QyCZCOs=7VBQg@mail.gmail.com>
Date: Fri, 28 Jun 2024 13:44:49 +0200
From: Ian Kumlien <ian.kumlien@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: IP oversized ip oacket from - header size should be skipped?

On Fri, Jun 28, 2024 at 1:28 PM Ian Kumlien <ian.kumlien@...il.com> wrote:
> On Fri, Jun 28, 2024 at 12:55 PM Ian Kumlien <ian.kumlien@...il.com> wrote:
> > On Fri, Jun 28, 2024 at 12:53 PM Florian Westphal <fw@...len.de> wrote:
> > > Ian Kumlien <ian.kumlien@...il.com> wrote:
> > > > Hi,
> > > >
> > > > In net/ipv4/ip_fragment.c line 412:
> > > > static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
> > > >                          struct sk_buff *prev_tail, struct net_device *dev)
> > > > {
> > > > ...
> > > >         len = ip_hdrlen(skb) + qp->q.len;
> > > >         err = -E2BIG;
> > > >         if (len > 65535)
> > > >                 goto out_oversize;
> > > > ....
> > > >
> > > > We can expand the expression to:
> > > > len = (ip_hdr(skb)->ihl * 4) + qp->q.len;
> > > >
> > > > But it's still weird since the definition of q->len is: "total length
> > > > of the original datagram"
> > >
> > > AFAICS datagram == l4 payload, so adding ihl is correct.
> >
> > But then it should be added and multiplied by the count of fragments?
> > which doesn't make sense to me...
> >
> > I have a security scanner that generates big packets (looking for
> > overflows using nmap nasl) that causes this to happen on send....
>
> So my thinking is that the packet is 65535 or thereabouts which would
> mean 44 segments, 43 would be 1500 bytes while the last one would be
> 1035
>
> To me it seems extremely unlikely that we would hit the limit in the
> case of all packets being l4 - but I'll do some more testing

So, I realize that i'm not the best at this but I can't get this to fit.

The 65535 comes from the 16 bit ip total length field, which includes
header and data.
The minimum length is 20 which would be just the IP header.

Now, IF we are comparing to 65535 then it HAS to be the full packet (ie l3)

If we are making this comparison with l4 data, then we are not RFC
compliant IMHO