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: <CAA85sZt8V=vL3BUJM3b9KEkK9gNaZ=dU_YZPj6m-CJD4fVQvwg@mail.gmail.com>
Date: Fri, 28 Jun 2024 13:28:19 +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 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