[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpWw_pP0zm8VgRoYgeMu=b8v8ECmXAcfSC8WGraQ8CNk+Q@mail.gmail.com>
Date: Wed, 22 Jan 2020 14:09:55 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: syzbot <syzbot+5af9a90dad568aa9f611@...kaller.appspotmail.com>,
David Miller <davem@...emloft.net>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>,
LKML <linux-kernel@...r.kernel.org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: KASAN: slab-out-of-bounds Read in __nla_put_nohdr
On Wed, Jan 22, 2020 at 12:33 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
>
> On 1/22/20 12:27 PM, Cong Wang wrote:
> > On Tue, Jan 21, 2020 at 11:55 AM Eric Dumazet <eric.dumazet@...il.com> wrote:
> >> em_nbyte_change() sets
> >> em->datalen = sizeof(*nbyte) + nbyte->len;
> >>
> >> But later tcf_em_validate() overwrites em->datalen with the user provide value (em->datalen = data_len; )
> >> which can be bigger than the allocated (kmemdup) space in em_nbyte_change()
> >>
> >> Should net/sched/em_nbyte.c() provide a dump() handler to avoid this issue ?
> >
> > I think for those who implement ->change() we should leave
> > ->datalen untouched to respect their choices. I don't see why
> > we have to set it twice.
> >
> >
>
> Agreed, but we need to audit them to make sure all of them are setting ->datalen
>
I audited all of them, either sets ->datalen in ->change() or just
implements a ops->datalen. I will send the patch out once passed
syzbot test.
Thanks.
Powered by blists - more mailing lists