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] [day] [month] [year] [list]
Message-ID: <CAHC9VhS08Mewdtmxr-v2EPfWUGBNX+vgDsErX01KjAVW5g8UQg@mail.gmail.com>
Date:   Thu, 2 Sep 2021 22:40:31 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Hillf Danton <hdanton@...a.com>
Cc:     syzbot <syzbot+c613e88b3093ebf3686e@...kaller.appspotmail.com>,
        bjorn.andersson@...aro.org, dan.carpenter@...cle.com,
        eric.dumazet@...il.com, linux-kernel@...r.kernel.org,
        manivannan.sadhasivam@...aro.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] WARNING: refcount bug in qrtr_node_lookup

On Thu, Sep 2, 2021 at 9:58 AM Paul Moore <paul@...l-moore.com> wrote:
>
> On Thu, Sep 2, 2021 at 12:13 AM Hillf Danton <hdanton@...a.com> wrote:
> > On Wed, 01 Sep 2021 19:32:06 -0700
> > >
> > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > UBSAN: object-size-mismatch in send4
> > >
> > > ================================================================================
> > > UBSAN: object-size-mismatch in ./include/net/flow.h:197:33
> > > member access within address 000000001597b753 with insufficient space
> > > for an object of type 'struct flowi'
> > > CPU: 1 PID: 231 Comm: kworker/u4:4 Not tainted 5.14.0-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > > Workqueue: wg-kex-wg0 wg_packet_handshake_send_worker
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:88 [inline]
> > >  dump_stack_lvl+0x15e/0x1d3 lib/dump_stack.c:105
> > >  ubsan_epilogue lib/ubsan.c:148 [inline]
> > >  handle_object_size_mismatch lib/ubsan.c:229 [inline]
> > >  ubsan_type_mismatch_common+0x1de/0x390 lib/ubsan.c:242
> > >  __ubsan_handle_type_mismatch_v1+0x41/0x50 lib/ubsan.c:271
> > >  flowi4_to_flowi_common include/net/flow.h:197 [inline]
> >
> > This was added in 3df98d79215a ("lsm,selinux: pass flowi_common instead of
> > flowi to the LSM hooks"), could you take a look at the UBSAN report, Paul?
>
> Sure, although due to some flooding here at home it might take a day
> (two?) before I have any real comments on this.

I'm looking quickly at this tonight after a long day so it's possible
I'm missing something, but in the original report if you look one step
before the backtrace above you see the caller is send4 in the
wireguard code, which starts off by creating it's own flowi4 variable
on the stack and then eventually passing it down to
flowi4_to_flowi_common() for use as the second parameter to
security_sk_classify_flow().  Because the wireguard code only
allocates a flowi4 and not a full flowi struct it seems like this
would explain the size mismatch warning (flowi is larger than flowi4
due to the union containing flowi6 as well as flowi4).

Off the top of my head it isn't clear to me if it is considered "safe"
to allocate just a flowi4 in this way, you may need to allocate a full
flowi; if none of the netdev folks reply we could always check the
other flowi4 users in the kernel.

Depending on the above, the fix may be either to adjust send4() to use
a full flowi, or to adjust flowi4_to_flowi_common() to use the
flowi_common struct at the top of the flowi4 struct instead of first
looking for the flowi struct and going from there.

-- 
paul moore
www.paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ