[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171227213627.GC23214@breakpoint.cc>
Date: Wed, 27 Dec 2017 22:36:27 +0100
From: Florian Westphal <fw@...len.de>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: syzbot <syzbot+4396883fa8c4f64e0175@...kaller.appspotmail.com>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs@...glegroups.com,
Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
Florian Westphal <fw@...len.de>,
David Miller <davem@...emloft.net>,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
netdev <netdev@...r.kernel.org>
Subject: Re: lost connection to test machine (3)
Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Wed, Dec 27, 2017 at 7:18 PM, syzbot
> <syzbot+4396883fa8c4f64e0175@...kaller.appspotmail.com> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > beacbc68ac3e23821a681adb30b45dc55b17488d
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> >
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: <syzbot+4396883fa8c4f64e0175@...kaller.appspotmail.com>
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
>
> +netfilter maintainers
>
> Here is cleaned reproducer:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <netinet/tcp.h>
> #include <linux/if.h>
> #include <linux/netfilter_ipv4/ip_tables.h>
>
> int main()
> {
> int fd;
>
> fd = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
> struct ipt_replace opt = {};
> opt.num_counters = 1;
> opt.size = -1;
> setsockopt(fd, SOL_IP, 0x40, &opt, 0x4);
> return 0;
> }
>
>
> What happens there is that here:
>
> struct xt_table_info *xt_alloc_table_info(unsigned int size)
> {
> ...
> if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages)
> return NULL;
>
> size = -1 and SMP_ALIGN(size) = 0, so this still tries to allocate
> 4GB+delta bytes.
>
> I don't understand why this uses SMP_ALIGN since we add 2 pages on
> top, it seems that we could just drop SMP_ALIGN and local SMP_ALIGN
> definition altogether.
Looking at history.git this seems to be a left over from back when
iptables allocated size * num_cpus() (and used an SMP_ALIGN based offset
for each cpu).
So yes, I think we can just toss/drop this.
Powered by blists - more mailing lists