Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Mon, 18 Sep 2023 09:58:00 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To:     David Howells <dhowells@redhat.com>,
        Eric Dumazet <edumazet@google.com>
Cc:     dhowells@redhat.com,
        syzbot <syzbot+62cbf263225ae13ff153@syzkaller.appspotmail.com>,
        bpf@vger.kernel.org, davem@davemloft.net, dsahern@kernel.org,
        kuba@kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, pabeni@redhat.com,
        syzkaller-bugs@googlegroups.com
Message-ID: <65085768c17da_898cd294ae@willemb.c.googlers.com.notmuch>
In-Reply-To: <3905046.1695031382@warthog.procyon.org.uk>
References: <3793723.1694795079@warthog.procyon.org.uk>
 <CANn89iLwMhOnrmQTZJ+BqZJSbJZ+Q4W6xRknAAr+uSrk5TX-EQ@mail.gmail.com>
 <0000000000001c12b30605378ce8@google.com>
 <3905046.1695031382@warthog.procyon.org.uk>
Subject: Re: [syzbot] [net?] WARNING in __ip6_append_data
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

David Howells wrote:
> David Howells <dhowells@redhat.com> wrote:
> 
> > I think the attached is probably an equivalent cleaned up reproducer.  Note
> > that if the length given to sendfile() is less than 65536, it fails with
> > EINVAL before it gets into __ip6_append_data().
> 
> Actually, it only fails with EINVAL if the size is not a multiple of the block
> size of the source file because it's open O_DIRECT so, say, 65536-512 is fine
> (and works).
> 
> But thinking more on this further, is this even a bug in my code, I wonder?
> The length passed is 65536 - but a UDP packet can't carry that, so it
> shouldn't it have errored out before getting that far?  (which is what it
> seems to do when I try it).
> 
> I don't see how we get past the length check in ip6_append_data() with the
> reproducer we're given unless the MTU is somewhat bigger than 65536 (is that
> even possible?)

An ipv6 packet can carry 64KB of payload, so maxnonfragsize of 65535 + 40
sounds correct. But payload length passed of 65536 is not (ignoring ipv6
jumbograms). So that should probably trigger an EINVAL -- if that is indeed
what the repro does.