* Re: netdevice notifier and device private data
From: Alexander Aring @ 2018-06-10 15:39 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, linux-wpan, linux-bluetooth
In-Reply-To: <29706.1528570878@localhost>
Hi,
On Sat, Jun 09, 2018 at 03:01:18PM -0400, Michael Richardson wrote:
>
> Alexander Aring <aring@mojatatu.com> wrote:
> > Futhermore user space programs e.g. radvd will do 6lowpan specific
> > handling on 6lowpan dev->type, it will not work either on tun
> > devices.
>
> > I know that wpantund from NestLabs do this switch, I am very
> > curious about the reason but I think they do it because the name
> > is 6LoWPAN. But wpantund is just a SLIP like protocol with
> > additional radio/foo commands.
>
> How do they change it then, and what does it do?
They change it with the ioctl() of tun characte device, see [0].
What it does, it just changing the interface type to something else,
also there is no check at all that Linux has this interface type.
User space software e.g. radvd [1] will evaluate this type and doing
specific handling. Obviously changing it to 6LoWPAN and using this code
will confuse everything, because the handling makes only sense for a
6LoWPAN Linux interface which actually also use the 6LoWPAN subsystem.
They just using tun as all other to feed a IPv6 stack on a remote
microcontroller e.g. openthread, contiki, riot. via slip. (wpantund also
allow some radio, foo configuration).
> It totally seems like broken behaviour. Maybe it's not even intentional.
> Maybe they are just foobar.
>
They simple don't know what they doing... somebody thought 6LoWPAN need
to be 6LoWPAN, but they actually don't use the 6LoWPAN handling inside
the kernel. _Except_ they doing out of tree stuff which I don't believe.
According to [0] it also works with tun default (I suppsoe raw IPv6),
because ifdef. And they should not change it because they don't use
in-kernel 6LoWPAN functionality.
I really think that this tun/tap feature makes a lot of trouble for some
type changes. I probably introduce lowpan_dev pointer to netdevice and
then check if it's really a 6LoPWAN interface, a dev->type will not
garantuee anymore you have a 6LoWPAN interface. At least in user space
it's not possible to have a check if you really have a 6LoWPAN interface.
- Alex
[0] https://github.com/openthread/wpantund/blob/master/src/util/tunnel.c#L180
[1] https://github.com/reubenhwk/radvd/blob/master/device-linux.c#L75
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in bpf_skb_change_proto
From: syzbot @ 2018-06-10 15:27 UTC (permalink / raw)
To: ast, daniel, davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: a16afaf7928b Merge tag 'for-v4.18' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1338f6bf800000
kernel config: https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca
dashboard link: https://syzkaller.appspot.com/bug?extid=d2d729bdde65dee3eae6
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1173381f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=171f90cf800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d2d729bdde65dee3eae6@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KASAN: slab-out-of-bounds in bpf_skb_proto_xlat net/core/filter.c:2637
[inline]
BUG: KASAN: slab-out-of-bounds in ____bpf_skb_change_proto
net/core/filter.c:2675 [inline]
BUG: KASAN: slab-out-of-bounds in bpf_skb_change_proto+0xe37/0x1300
net/core/filter.c:2650
Read of size 2 at addr ffff8801b04646c0 by task syz-executor241/4519
CPU: 0 PID: 4519 Comm: syz-executor241 Not tainted 4.17.0+ #93
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:431
bpf_skb_proto_xlat net/core/filter.c:2637 [inline]
____bpf_skb_change_proto net/core/filter.c:2675 [inline]
bpf_skb_change_proto+0xe37/0x1300 net/core/filter.c:2650
Allocated by task 0:
(stack is not available)
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8801b04646c0
which belongs to the cache skbuff_head_cache of size 232
The buggy address is located 0 bytes inside of
232-byte region [ffff8801b04646c0, ffff8801b04647a8)
The buggy address belongs to the page:
page:ffffea0006c11900 count:1 mapcount:0 mapping:ffff8801d9a0d080 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0006c49388 ffffea0006ae5c48 ffff8801d9a0d080
raw: 0000000000000000 ffff8801b0464080 000000010000000c 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b0464580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801b0464600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801b0464680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8801b0464700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801b0464780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [BUG] make htmldocs failed with error after add converted RST file.
From: Masanari Iida @ 2018-06-10 14:37 UTC (permalink / raw)
To: linux-kernel, jeffrey.t.kirsher, netdev, Jonathan Corbet,
linux-doc, intel-wired-lan
After merger a patch, make htmldocs and make xmldocs
failed with error.
reST markup error:
/home/iida/Repo/linux-2.6/Documentation/networking/e100.rst:90:
(SEVERE/4) Unexpected section title.
Configuring the Driver on Different Distributions
-------------------------------------------------
Documentation/Makefile:68: recipe for target 'htmldocs' failed
make[1]: *** [htmldocs] Error 1
Makefile:1542: recipe for target 'htmldocs' failed
make: *** [htmldocs] Error 2
85d63445f41125dafeddda74e5b13b7eefac9407 is the first bad commit
commit 85d63445f41125dafeddda74e5b13b7eefac9407
Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu May 10 12:20:13 2018 -0700
Documentation: e100: Update the Intel 10/100 driver doc
Reported-by: Masanari Iida <standby24x7@gmail.com>
Masanari Iida
^ permalink raw reply
* Re: UML build broken on master
From: Geert Uytterhoeven @ 2018-06-10 14:04 UTC (permalink / raw)
To: Thomas Meyer
Cc: alexei.starovoitov, netdev, Alexei Starovoitov, David S. Miller,
Arnd Bergmann, Linux Kernel Mailing List, yuehaibing,
Daniel Borkmann
In-Reply-To: <ae09ac81-c2a5-4a18-bb7f-61219b0c0ac4@email.android.com>
On Sun, Jun 10, 2018 at 3:49 PM Thomas Meyer <thomas@m3y3r.de> wrote:
>The umh stuff seems to have broken this build config:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/13394304/
>
> Bug or feature?
Bug. It's broken everywhere except for native X86.
Multiple patches to fix this are floating around.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Björn Töpel @ 2018-06-10 13:03 UTC (permalink / raw)
To: penguin-kernel
Cc: dvyukov, syzbot+4abadc5d69117b346506, Björn Töpel,
Karlsson, Magnus, David Miller, LKML, Netdev, syzkaller-bugs
In-Reply-To: <13f6777a-2170-d0cc-1066-1b48a27ec981@i-love.sakura.ne.jp>
Den sön 10 juni 2018 kl 14:53 skrev Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp>:
>
> On 2018/06/10 20:52, Dmitry Vyukov wrote:
> > On Sun, Jun 10, 2018 at 11:31 AM, Björn Töpel <bjorn.topel@gmail.com> wrote:
> >> Den sön 10 juni 2018 kl 04:53 skrev Tetsuo Handa
> >> <penguin-kernel@i-love.sakura.ne.jp>:
> >>>
> >>> On 2018/06/10 7:47, syzbot wrote:
> >>>> Hello,
> >>>>
> >>>> syzbot found the following crash on:
> >>>>
> >>>> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
> >>>> git tree: upstream
> >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
> >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
> >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
> >>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
> >>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
> >>>>
> >>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >>>> Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
> >>>>
> >>>> random: sshd: uninitialized urandom read (32 bytes read)
> >>>> random: sshd: uninitialized urandom read (32 bytes read)
> >>>> random: sshd: uninitialized urandom read (32 bytes read)
> >>>> random: sshd: uninitialized urandom read (32 bytes read)
> >>>> random: sshd: uninitialized urandom read (32 bytes read)
> >>>> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> >>>> Kernel panic - not syncing: panic_on_warn set ...
> >>>
> >>> syzbot gave up upon kmalloc(), but actually error handling path has
> >>> NULL pointer dereference bug.
> >>>
> >>
> >> Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
> >> c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
> >
> > Let's tell syzbot about this:
> >
> > #syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
> >
> >
> Excuse me, but that patch fixes NULL pointer dereference which occurs after kmalloc()'s
> "WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996"
> message. That is, "Too large memory allocation" itself is not yet fixed.
The code relies on that the sl{u,a,o}b layer says no, and the
setsockopt bails out. The warning could be opted out using
__GFP_NOWARN. Is there another preferred way? Two get_user_pages
calls, where the first call would set pages to NULL just to fault the
region? Walk the process' VMAs? Something else?
Björn
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Dmitry Vyukov @ 2018-06-10 12:58 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Björn Töpel, syzbot+4abadc5d69117b346506,
Björn Töpel, Karlsson, Magnus, David Miller, LKML,
Netdev, syzkaller-bugs
In-Reply-To: <13f6777a-2170-d0cc-1066-1b48a27ec981@i-love.sakura.ne.jp>
On Sun, Jun 10, 2018 at 2:53 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2018/06/10 20:52, Dmitry Vyukov wrote:
>> On Sun, Jun 10, 2018 at 11:31 AM, Björn Töpel <bjorn.topel@gmail.com> wrote:
>>> Den sön 10 juni 2018 kl 04:53 skrev Tetsuo Handa
>>> <penguin-kernel@i-love.sakura.ne.jp>:
>>>>
>>>> On 2018/06/10 7:47, syzbot wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot found the following crash on:
>>>>>
>>>>> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
>>>>> git tree: upstream
>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
>>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
>>>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
>>>>>
>>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>>> Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
>>>>>
>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>
>>>> syzbot gave up upon kmalloc(), but actually error handling path has
>>>> NULL pointer dereference bug.
>>>>
>>>
>>> Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
>>> c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
>>
>> Let's tell syzbot about this:
>>
>> #syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
>>
>>
> Excuse me, but that patch fixes NULL pointer dereference which occurs after kmalloc()'s
> "WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996"
> message. That is, "Too large memory allocation" itself is not yet fixed.
You are right! I fixed it up. Thanks
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Tetsuo Handa @ 2018-06-10 12:53 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Björn Töpel, syzbot+4abadc5d69117b346506,
Björn Töpel, Karlsson, Magnus, David Miller, LKML,
Netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+bfZK6yucoDrXPPW3Tc40RYq61u0Zcb=CKtdao8E+v1cQ@mail.gmail.com>
On 2018/06/10 20:52, Dmitry Vyukov wrote:
> On Sun, Jun 10, 2018 at 11:31 AM, Björn Töpel <bjorn.topel@gmail.com> wrote:
>> Den sön 10 juni 2018 kl 04:53 skrev Tetsuo Handa
>> <penguin-kernel@i-love.sakura.ne.jp>:
>>>
>>> On 2018/06/10 7:47, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following crash on:
>>>>
>>>> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
>>>> git tree: upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
>>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
>>>>
>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>> Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
>>>>
>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>
>>> syzbot gave up upon kmalloc(), but actually error handling path has
>>> NULL pointer dereference bug.
>>>
>>
>> Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
>> c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
>
> Let's tell syzbot about this:
>
> #syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
>
>
Excuse me, but that patch fixes NULL pointer dereference which occurs after kmalloc()'s
"WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996"
message. That is, "Too large memory allocation" itself is not yet fixed.
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Dmitry Vyukov @ 2018-06-10 11:52 UTC (permalink / raw)
To: Björn Töpel
Cc: Tetsuo Handa, syzbot+4abadc5d69117b346506, Björn Töpel,
Karlsson, Magnus, David Miller, LKML, Netdev, syzkaller-bugs
In-Reply-To: <CAJ+HfNhnmvTHsE7cgi8pROjprsYvCZuzZDmYmpiUx4jqtHboUw@mail.gmail.com>
On Sun, Jun 10, 2018 at 11:31 AM, Björn Töpel <bjorn.topel@gmail.com> wrote:
> Den sön 10 juni 2018 kl 04:53 skrev Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp>:
>>
>> On 2018/06/10 7:47, syzbot wrote:
>> > Hello,
>> >
>> > syzbot found the following crash on:
>> >
>> > HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
>> > git tree: upstream
>> > console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
>> > kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
>> > dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
>> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
>> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
>> >
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> > WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
>> > Kernel panic - not syncing: panic_on_warn set ...
>>
>> syzbot gave up upon kmalloc(), but actually error handling path has
>> NULL pointer dereference bug.
>>
>
> Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
> c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
Let's tell syzbot about this:
#syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
^ permalink raw reply
* Re: [PATCH bpf-next v2 3/3] bpf: add ability to configure BPF JIT kallsyms export at the boot time
From: kbuild test robot @ 2018-06-10 11:42 UTC (permalink / raw)
To: Eugene Syromiatnikov
Cc: kbuild-all, netdev, linux-kernel, linux-doc, Kees Cook,
Kai-Heng Feng, Daniel Borkmann, Alexei Starovoitov,
Jonathan Corbet, Jiri Olsa, Jesper Dangaard Brouer
In-Reply-To: <20180523121837.GA31550@asgard.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
Hi Eugene,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Eugene-Syromiatnikov/bpf-add-boot-parameters-for-sysctl-knobs/20180526-164048
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-randconfig-x074-06101602 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> kernel//bpf/core.c:325:38: error: 'CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM_VALUE' undeclared here (not in a function); did you mean 'CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM'?
int bpf_jit_kallsyms __read_mostly = CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM_VALUE;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM
vim +325 kernel//bpf/core.c
323
324 #ifdef CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM
> 325 int bpf_jit_kallsyms __read_mostly = CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM_VALUE;
326
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30098 bytes --]
^ permalink raw reply
* Re: [PATCH] fs: 9p: Adding new return type vm_fault_t
From: Souptick Joarder @ 2018-06-10 9:56 UTC (permalink / raw)
To: Eric Van Hensbergen, rminnich, Latchesar Ionkov
Cc: v9fs-developer, Matthew Wilcox, netdev, linux-kernel
In-Reply-To: <20180610095640.GA4061@jordon-HP-15-Notebook-PC>
On Sun, Jun 10, 2018 at 3:26 PM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> Use new return type vm_fault_t for page_mkwrite
> handler.
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
> ---
> fs/9p/vfs_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
> index 03c9e32..5f2e48d 100644
> --- a/fs/9p/vfs_file.c
> +++ b/fs/9p/vfs_file.c
> @@ -533,7 +533,7 @@ int v9fs_file_fsync_dotl(struct file *filp, loff_t start, loff_t end,
> return retval;
> }
>
> -static int
> +static vm_fault_t
> v9fs_vm_page_mkwrite(struct vm_fault *vmf)
> {
> struct v9fs_inode *v9inode;
> --
> 1.9.1
>
Eric, as requested, posted it in net-dev and lkml mailing list.
^ permalink raw reply
* [PATCH] fs: 9p: Adding new return type vm_fault_t
From: Souptick Joarder @ 2018-06-10 9:56 UTC (permalink / raw)
To: ericvh, rminnich, lucho; +Cc: v9fs-developer, willy, netdev, linux-kernel
Use new return type vm_fault_t for page_mkwrite
handler.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
---
fs/9p/vfs_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 03c9e32..5f2e48d 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -533,7 +533,7 @@ int v9fs_file_fsync_dotl(struct file *filp, loff_t start, loff_t end,
return retval;
}
-static int
+static vm_fault_t
v9fs_vm_page_mkwrite(struct vm_fault *vmf)
{
struct v9fs_inode *v9inode;
^ permalink raw reply related
* Re: [PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Geert Uytterhoeven @ 2018-06-10 9:34 UTC (permalink / raw)
To: Michael Schmitz
Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain, Michael Karcher
In-Reply-To: <1528604559-972-3-git-send-email-schmitzmic@gmail.com>
On Sun, Jun 10, 2018 at 6:22 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Now that ax88796.c exports the ax_NS8390_reinit() symbol, we can
> include 8390.h instead of lib8390.c, avoiding duplication of that
> function and killing a few compile warnings in the bargain.
>
> Fixes: 861928f4e60e826c ("net-next: New ax88796 platform
> driver for Amiga X-Surf 100 Zorro board (m68k)")
>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook
From: Geert Uytterhoeven @ 2018-06-10 9:34 UTC (permalink / raw)
To: Michael Schmitz
Cc: netdev, Linux/m68k, Andrew Lunn, Finn Thain, Michael Karcher
In-Reply-To: <1528604559-972-2-git-send-email-schmitzmic@gmail.com>
Hi Michael,
Thanks for the update!
On Sun, Jun 10, 2018 at 6:22 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> The block I/O code for the new X-Surf 100 ax88796 driver needs
> ax_NS8390_init() for error fixup in its block_output function.
>
> Export this static function through the ax_NS8390_reinit()
> wrapper so we can lose the lib8380.c include in the X-Surf 100
> driver.
>
> Fixes: 861928f4e60e826c ("net-next: New ax88796 platform
> driver for Amiga X-Surf 100 Zorro board (m68k)")
>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Björn Töpel @ 2018-06-10 9:31 UTC (permalink / raw)
To: penguin-kernel
Cc: syzbot+4abadc5d69117b346506, Björn Töpel,
Karlsson, Magnus, David Miller, LKML, Netdev, syzkaller-bugs
In-Reply-To: <10d6b170-b820-3077-8737-c9d06e98d0fb@I-love.SAKURA.ne.jp>
Den sön 10 juni 2018 kl 04:53 skrev Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp>:
>
> On 2018/06/10 7:47, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
> >
> > random: sshd: uninitialized urandom read (32 bytes read)
> > random: sshd: uninitialized urandom read (32 bytes read)
> > random: sshd: uninitialized urandom read (32 bytes read)
> > random: sshd: uninitialized urandom read (32 bytes read)
> > random: sshd: uninitialized urandom read (32 bytes read)
> > WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> > Kernel panic - not syncing: panic_on_warn set ...
>
> syzbot gave up upon kmalloc(), but actually error handling path has
> NULL pointer dereference bug.
>
Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
Björn
> ----------
> #include <sys/socket.h>
> #include <unistd.h>
> #define PF_XDP 44
> #define SOL_XDP 283
> #define XDP_UMEM_REG 4
>
> int main(int argc, char *argv[])
> {
> int fd = socket(PF_XDP, SOCK_RAW, 0);
> struct xdp_umem_reg {
> unsigned long long addr;
> unsigned long long len;
> unsigned int chunk_size;
> unsigned int headroom;
> } arg = {
> 0x20000000,
> 0x200002000,
> 0x800,
> 2
> };
> setsockopt(fd, SOL_XDP, XDP_UMEM_REG, &arg, sizeof(arg));
> return 0;
> }
> ----------
>
> [ 95.172962] WARNING: CPU: 3 PID: 2891 at mm/page_alloc.c:4065 __alloc_pages_nodemask+0x283/0xdf0
> [ 95.175179] Modules linked in: pcspkr sg vmw_vmci i2c_piix4 sd_mod ata_generic pata_acpi ahci libahci vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mptspi scsi_transport_spi i2c_core mptscsih e1000 mptbase libata serio_raw
> [ 95.180614] CPU: 3 PID: 2891 Comm: a.out Kdump: loaded Not tainted 4.17.0+ #421
> [ 95.182351] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
> [ 95.184909] RIP: 0010:__alloc_pages_nodemask+0x283/0xdf0
> [ 95.186319] Code: 00 00 04 00 41 0f 44 c6 48 3b 5c 24 78 c6 84 24 90 00 00 00 00 0f 85 50 0b 00 00 41 83 fd 0a 76 1d f6 c4 02 0f 85 3b ff ff ff <0f> 0b e9 34 ff ff ff 0f 0b 0f 1f 40 00 e9 10 fe ff ff 0f 0b 89 c2
> [ 95.190997] RSP: 0018:ffffc900008efd20 EFLAGS: 00010246
> [ 95.192257] RAX: 000000000060c0c0 RBX: 0000000000000000 RCX: ffff88013f7fe920
> [ 95.194005] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
> [ 95.195697] RBP: 000000000060c0c0 R08: 0000000000000001 R09: ffffffffffffef81
> [ 95.197393] R10: 000000000000000d R11: 0000000000000e8c R12: 0000000000000001
> [ 95.199084] R13: 000000000000000d R14: 000000000060c0c0 R15: 0000000000000000
> [ 95.200735] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
> [ 95.203441] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 95.205726] CR2: 0000000020000040 CR3: 0000000133e2c006 CR4: 00000000001606e0
> [ 95.207743] Call Trace:
> [ 95.208427] ? __lock_acquire+0x22a/0x1830
> [ 95.209391] ? kmalloc_order+0x15/0x60
> [ 95.210266] ? __kmalloc+0x20a/0x210
> [ 95.211104] ? xdp_umem_create+0x16e/0x3c0
> [ 95.212095] ? xsk_setsockopt+0x153/0x1a0
> [ 95.213143] ? __sys_setsockopt+0x67/0xb0
> [ 95.214058] ? __x64_sys_setsockopt+0x1b/0x20
> [ 95.215040] ? do_syscall_64+0x4f/0x1f0
> [ 95.215890] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 95.217079] irq event stamp: 5296
> [ 95.217785] hardirqs last enabled at (5295): [<ffffffff810b2a77>] __raw_spin_lock_init+0x17/0x50
> [ 95.220381] hardirqs last disabled at (5296): [<ffffffff81800f33>] error_entry+0x73/0xc0
> [ 95.222447] softirqs last enabled at (5284): [<ffffffff81a00183>] __do_softirq+0x183/0x204
> [ 95.224328] softirqs last disabled at (5277): [<ffffffff81061bcd>] irq_exit+0xcd/0xf0
> [ 95.226065] ---[ end trace 75b6f67917663997 ]---
> [ 95.227250] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
> [ 95.229101] PGD 1342eb067 P4D 1342eb067 PUD 1314a2067 PMD 0
> [ 95.230398] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
> [ 95.231418] CPU: 3 PID: 2891 Comm: a.out Kdump: loaded Tainted: G W 4.17.0+ #421
> [ 95.233474] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
> [ 95.236636] RIP: 0010:xdp_umem_create+0x228/0x3c0
> [ 95.237867] Code: f4 ff ff ff e8 b9 f9 ff ff 48 8b bb 90 00 00 00 e8 3d d9 a7 ff 48 c7 83 90 00 00 00 00 00 00 00 48 8b 43 30 8b 93 98 00 00 00 <f0> 48 29 50 60 48 8b 7b 30 49 63 ec e8 57 10 92 ff 48 8b 7b 38 e8
> [ 95.241945] RSP: 0018:ffffc900008efe88 EFLAGS: 00010246
> [ 95.243236] RAX: 0000000000000000 RBX: ffff880133401288 RCX: 000000000060c0c0
> [ 95.244789] RDX: 0000000000200002 RSI: 0000000001000010 RDI: 0000000000000000
> [ 95.247382] RBP: 0000000000200002 R08: 0000000000000001 R09: ffffffffffffef81
> [ 95.249735] R10: 000000000000000d R11: 0000000000000e8c R12: 00000000fffffff4
> [ 95.252391] R13: 0000000000000040 R14: 0000000020000000 R15: 00000000000007c0
> [ 95.255280] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
> [ 95.257918] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 95.260068] CR2: 0000000000000060 CR3: 0000000133e2c006 CR4: 00000000001606e0
> [ 95.262535] Call Trace:
> [ 95.263900] ? xsk_setsockopt+0x153/0x1a0
> [ 95.265495] ? __sys_setsockopt+0x67/0xb0
> [ 95.267108] ? __x64_sys_setsockopt+0x1b/0x20
> [ 95.269532] ? do_syscall_64+0x4f/0x1f0
> [ 95.271474] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 95.273292] Modules linked in: pcspkr sg vmw_vmci i2c_piix4 sd_mod ata_generic pata_acpi ahci libahci vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mptspi scsi_transport_spi i2c_core mptscsih e1000 mptbase libata serio_raw
> [ 95.279548] CR2: 0000000000000060
> [ 95.281044] ---[ end trace 75b6f67917663998 ]---
> [ 95.283132] RIP: 0010:xdp_umem_create+0x228/0x3c0
> [ 95.285257] Code: f4 ff ff ff e8 b9 f9 ff ff 48 8b bb 90 00 00 00 e8 3d d9 a7 ff 48 c7 83 90 00 00 00 00 00 00 00 48 8b 43 30 8b 93 98 00 00 00 <f0> 48 29 50 60 48 8b 7b 30 49 63 ec e8 57 10 92 ff 48 8b 7b 38 e8
> [ 95.291487] RSP: 0018:ffffc900008efe88 EFLAGS: 00010246
> [ 95.293429] RAX: 0000000000000000 RBX: ffff880133401288 RCX: 000000000060c0c0
> [ 95.295761] RDX: 0000000000200002 RSI: 0000000001000010 RDI: 0000000000000000
> [ 95.298072] RBP: 0000000000200002 R08: 0000000000000001 R09: ffffffffffffef81
> [ 95.300403] R10: 000000000000000d R11: 0000000000000e8c R12: 00000000fffffff4
> [ 95.303699] R13: 0000000000000040 R14: 0000000020000000 R15: 00000000000007c0
> [ 95.306178] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
> [ 95.308645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 95.310782] CR2: 0000000000000060 CR3: 0000000133e2c006 CR4: 00000000001606e0
>
> xdp_umem_create+0x228/0x3c0:
> arch_atomic64_sub at arch/x86/include/asm/atomic64_64.h:60
> (inlined by) atomic64_sub at include/asm-generic/atomic-instrumented.h:145
> (inlined by) atomic_long_sub at include/asm-generic/atomic-long.h:199
> (inlined by) xdp_umem_unaccount_pages at net/xdp/xdp_umem.c:135
> (inlined by) xdp_umem_reg at net/xdp/xdp_umem.c:334
> (inlined by) xdp_umem_create at net/xdp/xdp_umem.c:349
^ permalink raw reply
* KASAN: slab-out-of-bounds Write in tls_push_record
From: syzbot @ 2018-06-10 6:15 UTC (permalink / raw)
To: aviadye, borisp, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 410feb75de24 Merge tag 'arm64-upstream' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1308a0cf800000
kernel config: https://syzkaller.appspot.com/x/.config?x=7c0dfd1fff57e223
dashboard link: https://syzkaller.appspot.com/bug?extid=5c74af81c547738e1684
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5c74af81c547738e1684@syzkaller.appspotmail.com
RDX: 00000000fffffdef RSI: 00000000200005c0 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000020000000 R09: 000000000000001c
R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000015
R13: 00000000004c0d3b R14: 00000000004d07a8 R15: 0000000000000002
==================================================================
BUG: KASAN: slab-out-of-bounds in tls_fill_prepend include/net/tls.h:339
[inline]
BUG: KASAN: slab-out-of-bounds in tls_push_record+0x1023/0x13e0
net/tls/tls_sw.c:240
Write of size 1 at addr ffff8801bae68000 by task syz-executor1/24187
CPU: 1 PID: 24187 Comm: syz-executor1 Not tainted 4.17.0+ #91
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
tls_fill_prepend include/net/tls.h:339 [inline]
tls_push_record+0x1023/0x13e0 net/tls/tls_sw.c:240
tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
tls_push_pending_closed_record+0x10c/0x150 net/tls/tls_main.c:211
tls_complete_pending_work include/net/tls.h:277 [inline]
tls_sk_proto_close+0x8f2/0xad0 net/tls/tls_main.c:263
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
sock_release+0x96/0x1b0 net/socket.c:598
sock_close+0x16/0x20 net/socket.c:1174
__fput+0x353/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2478
do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4559f9
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fb96babace8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000072bec8 RCX: 00000000004559f9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072bec8
RBP: 000000000072bec8 R08: 0000000000000033 R09: 000000000072bea0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd163d2bff R14: 00007fb96babb9c0 R15: 0000000000000000
Allocated by task 24192:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc mm/slab.c:3718 [inline]
__kmalloc+0x14e/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:518 [inline]
rw_copy_check_uvector+0x31e/0x3a0 fs/read_write.c:781
import_iovec+0xc3/0x420 lib/iov_iter.c:1459
vfs_readv+0xe2/0x1a0 fs/read_write.c:984
do_preadv+0x1ba/0x270 fs/read_write.c:1070
__do_sys_preadv fs/read_write.c:1120 [inline]
__se_sys_preadv fs/read_write.c:1115 [inline]
__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 24192:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
import_iovec+0x32e/0x420 lib/iov_iter.c:1463
vfs_readv+0xe2/0x1a0 fs/read_write.c:984
do_preadv+0x1ba/0x270 fs/read_write.c:1070
__do_sys_preadv fs/read_write.c:1120 [inline]
__se_sys_preadv fs/read_write.c:1115 [inline]
__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801bae69f80
which belongs to the cache kmalloc-16384 of size 16384
The buggy address is located 8064 bytes to the left of
16384-byte region [ffff8801bae69f80, ffff8801bae6df80)
The buggy address belongs to the page:
page:ffffea0006eb9a00 count:1 mapcount:0 mapping:ffff8801da802200 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0005e2a408 ffff8801da801c48 ffff8801da802200
raw: 0000000000000000 ffff8801bae69f80 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801bae67f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801bae67f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801bae68000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8801bae68080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801bae68100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: linux-next: Please add mlx5-next tree
From: Leon Romanovsky @ 2018-06-10 5:41 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Saeed Mahameed, Jason Gunthorpe, Doug Ledford, David S. Miller,
linux-netdev, RDMA mailing list
In-Reply-To: <20180608074726.5b3883e2@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Fri, Jun 08, 2018 at 07:47:26AM +1000, Stephen Rothwell wrote:
> Hi Leon,
>
> On Wed, 6 Jun 2018 22:25:00 +0300 Leon Romanovsky <leon@kernel.org> wrote:
> >
> > Can you please add the branch "mlx5-next" from the following tree to the
> > linux-next integration tree?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/
> >
> > The mlx5-next branch is used to send shared pull requests to both netdev
> > and RDMA subsystems and it is worth to have linux-next coverage on it
> > before.
>
> I try hard not to add new trees during the merge window, sorry. If I
> forget to add it after -rc1 has been released, please remind me.
Thanks Stephen, I'll do.
>
> --
> Cheers,
> Stephen Rothwell
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: linux-next: Please add mlx5-next tree
From: Leon Romanovsky @ 2018-06-10 5:40 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, Saeed Mahameed, Jason Gunthorpe,
Doug Ledford, David S. Miller, linux-netdev, RDMA mailing list
In-Reply-To: <20180608161945.66f4628f@xeon-e3>
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Fri, Jun 08, 2018 at 04:19:45PM -0700, Stephen Hemminger wrote:
> On Wed, 6 Jun 2018 22:25:00 +0300
> Leon Romanovsky <leon@kernel.org> wrote:
>
> > Hi Stephen,
> >
> > Can you please add the branch "mlx5-next" from the following tree to the
> > linux-next integration tree?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/
> >
> > The mlx5-next branch is used to send shared pull requests to both netdev
> > and RDMA subsystems and it is worth to have linux-next coverage on it
> > before.
> >
> > Thanks
>
> I would hope all network drivers keep getting review in netdev.
> Don't want a path to upstream that bypasses review.
Me too, this branch/tree is intended for patches AFTER they passed review
in netdev and/or RDMA.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook
From: Michael Schmitz @ 2018-06-10 4:22 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, kernel, Michael Schmitz
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
The block I/O code for the new X-Surf 100 ax88796 driver needs
ax_NS8390_init() for error fixup in its block_output function.
Export this static function through the ax_NS8390_reinit()
wrapper so we can lose the lib8380.c include in the X-Surf 100
driver.
Fixes: 861928f4e60e826c ("net-next: New ax88796 platform
driver for Amiga X-Surf 100 Zorro board (m68k)")
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/ax88796.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index 2a0ddec..673d154 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -104,6 +104,13 @@ struct ax_device {
return (struct ax_device *)(ei_local + 1);
}
+void ax_NS8390_reinit(struct net_device *dev)
+{
+ ax_NS8390_init(dev, 1);
+}
+
+EXPORT_SYMBOL_GPL(ax_NS8390_reinit);
+
/*
* ax_initial_check
*
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] net-next: xsurf100: drop include of lib8390.c
From: Michael Schmitz @ 2018-06-10 4:22 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, kernel, Michael Schmitz
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
Now that ax88796.c exports the ax_NS8390_reinit() symbol, we can
include 8390.h instead of lib8390.c, avoiding duplication of that
function and killing a few compile warnings in the bargain.
Fixes: 861928f4e60e826c ("net-next: New ax88796 platform
driver for Amiga X-Surf 100 Zorro board (m68k)")
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
---
drivers/net/ethernet/8390/xsurf100.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/8390/xsurf100.c b/drivers/net/ethernet/8390/xsurf100.c
index e2c9638..1c3e8d1 100644
--- a/drivers/net/ethernet/8390/xsurf100.c
+++ b/drivers/net/ethernet/8390/xsurf100.c
@@ -22,8 +22,6 @@
#define XS100_8390_DATA_WRITE32_BASE 0x0C80
#define XS100_8390_DATA_AREA_SIZE 0x80
-#define __NS8390_init ax_NS8390_init
-
/* force unsigned long back to 'void __iomem *' */
#define ax_convert_addr(_a) ((void __force __iomem *)(_a))
@@ -42,10 +40,11 @@
/* Ensure we have our RCR base value */
#define AX88796_PLATFORM
-static unsigned char version[] =
- "ax88796.c: Copyright 2005,2007 Simtec Electronics\n";
+#define NS8390_CORE
+#include "8390.h"
-#include "lib8390.c"
+/* exported from ax88796.c, especially for our benefit */
+extern void ax_NS8390_reinit(struct net_device *dev);
/* from ne.c */
#define NE_CMD EI_SHIFT(0x00)
@@ -232,7 +231,7 @@ static void xs100_block_output(struct net_device *dev, int count,
if (jiffies - dma_start > 2 * HZ / 100) { /* 20ms */
netdev_warn(dev, "timeout waiting for Tx RDC.\n");
ei_local->reset_8390(dev);
- ax_NS8390_init(dev, 1);
+ ax_NS8390_reinit(dev);
break;
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/2] net-next: cleanup use of lib8390.c code in xsurf100.c
From: Michael Schmitz @ 2018-06-10 4:22 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, andrew, geert, fthain, kernel
In-Reply-To: <CAMuHMdVfjE=+YiqCrPfGObeYYkQwKGiQEWyprQr-n9z7J9-X-A@mail.gmail.com>
As suggested by Geert, xsurf100.c really does not need to duplicate code
from lib8390.c which is already part of ax88796.c, by including that file.
All we need from lib8390.c in the xsurf100 block output function is one
single function: ax_NS8390_init(). Export this symbol through a wrapper in
ax88796.c (the original __NS8390_init() is a static function) so the
xsurf100 driver can use it.
This is rather a quick band-aid fix to deal with the ugliest code duplication
(including lib8390.c where it really isn't needed). The xsurf100 block_input
and block_output functions are almost exact duplicates of the generic ax88796
functions, and changing those to make use of platform-specific block MMIO
transfer functions would allow all duplicated code to be removed from
xsurf100.c. This will be addressed in a later patch.
Changes from earlier RFC version:
- rebased on net-next so patch 2 applies cleanly
- use a non-static wrapper for ax_NS8390_init() alias __NS8390_init() so
this driver can be compiled in.
Tested on Amiga hardware (elgar).
Cheers,
Michael
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Tetsuo Handa @ 2018-06-10 2:48 UTC (permalink / raw)
To: syzbot, bjorn.topel, magnus.karlsson
Cc: davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <00000000000092de58056e3d4b96@google.com>
On 2018/06/10 7:47, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
> dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> Kernel panic - not syncing: panic_on_warn set ...
syzbot gave up upon kmalloc(), but actually error handling path has
NULL pointer dereference bug.
----------
#include <sys/socket.h>
#include <unistd.h>
#define PF_XDP 44
#define SOL_XDP 283
#define XDP_UMEM_REG 4
int main(int argc, char *argv[])
{
int fd = socket(PF_XDP, SOCK_RAW, 0);
struct xdp_umem_reg {
unsigned long long addr;
unsigned long long len;
unsigned int chunk_size;
unsigned int headroom;
} arg = {
0x20000000,
0x200002000,
0x800,
2
};
setsockopt(fd, SOL_XDP, XDP_UMEM_REG, &arg, sizeof(arg));
return 0;
}
----------
[ 95.172962] WARNING: CPU: 3 PID: 2891 at mm/page_alloc.c:4065 __alloc_pages_nodemask+0x283/0xdf0
[ 95.175179] Modules linked in: pcspkr sg vmw_vmci i2c_piix4 sd_mod ata_generic pata_acpi ahci libahci vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mptspi scsi_transport_spi i2c_core mptscsih e1000 mptbase libata serio_raw
[ 95.180614] CPU: 3 PID: 2891 Comm: a.out Kdump: loaded Not tainted 4.17.0+ #421
[ 95.182351] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 95.184909] RIP: 0010:__alloc_pages_nodemask+0x283/0xdf0
[ 95.186319] Code: 00 00 04 00 41 0f 44 c6 48 3b 5c 24 78 c6 84 24 90 00 00 00 00 0f 85 50 0b 00 00 41 83 fd 0a 76 1d f6 c4 02 0f 85 3b ff ff ff <0f> 0b e9 34 ff ff ff 0f 0b 0f 1f 40 00 e9 10 fe ff ff 0f 0b 89 c2
[ 95.190997] RSP: 0018:ffffc900008efd20 EFLAGS: 00010246
[ 95.192257] RAX: 000000000060c0c0 RBX: 0000000000000000 RCX: ffff88013f7fe920
[ 95.194005] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
[ 95.195697] RBP: 000000000060c0c0 R08: 0000000000000001 R09: ffffffffffffef81
[ 95.197393] R10: 000000000000000d R11: 0000000000000e8c R12: 0000000000000001
[ 95.199084] R13: 000000000000000d R14: 000000000060c0c0 R15: 0000000000000000
[ 95.200735] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
[ 95.203441] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.205726] CR2: 0000000020000040 CR3: 0000000133e2c006 CR4: 00000000001606e0
[ 95.207743] Call Trace:
[ 95.208427] ? __lock_acquire+0x22a/0x1830
[ 95.209391] ? kmalloc_order+0x15/0x60
[ 95.210266] ? __kmalloc+0x20a/0x210
[ 95.211104] ? xdp_umem_create+0x16e/0x3c0
[ 95.212095] ? xsk_setsockopt+0x153/0x1a0
[ 95.213143] ? __sys_setsockopt+0x67/0xb0
[ 95.214058] ? __x64_sys_setsockopt+0x1b/0x20
[ 95.215040] ? do_syscall_64+0x4f/0x1f0
[ 95.215890] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 95.217079] irq event stamp: 5296
[ 95.217785] hardirqs last enabled at (5295): [<ffffffff810b2a77>] __raw_spin_lock_init+0x17/0x50
[ 95.220381] hardirqs last disabled at (5296): [<ffffffff81800f33>] error_entry+0x73/0xc0
[ 95.222447] softirqs last enabled at (5284): [<ffffffff81a00183>] __do_softirq+0x183/0x204
[ 95.224328] softirqs last disabled at (5277): [<ffffffff81061bcd>] irq_exit+0xcd/0xf0
[ 95.226065] ---[ end trace 75b6f67917663997 ]---
[ 95.227250] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
[ 95.229101] PGD 1342eb067 P4D 1342eb067 PUD 1314a2067 PMD 0
[ 95.230398] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[ 95.231418] CPU: 3 PID: 2891 Comm: a.out Kdump: loaded Tainted: G W 4.17.0+ #421
[ 95.233474] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 95.236636] RIP: 0010:xdp_umem_create+0x228/0x3c0
[ 95.237867] Code: f4 ff ff ff e8 b9 f9 ff ff 48 8b bb 90 00 00 00 e8 3d d9 a7 ff 48 c7 83 90 00 00 00 00 00 00 00 48 8b 43 30 8b 93 98 00 00 00 <f0> 48 29 50 60 48 8b 7b 30 49 63 ec e8 57 10 92 ff 48 8b 7b 38 e8
[ 95.241945] RSP: 0018:ffffc900008efe88 EFLAGS: 00010246
[ 95.243236] RAX: 0000000000000000 RBX: ffff880133401288 RCX: 000000000060c0c0
[ 95.244789] RDX: 0000000000200002 RSI: 0000000001000010 RDI: 0000000000000000
[ 95.247382] RBP: 0000000000200002 R08: 0000000000000001 R09: ffffffffffffef81
[ 95.249735] R10: 000000000000000d R11: 0000000000000e8c R12: 00000000fffffff4
[ 95.252391] R13: 0000000000000040 R14: 0000000020000000 R15: 00000000000007c0
[ 95.255280] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
[ 95.257918] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.260068] CR2: 0000000000000060 CR3: 0000000133e2c006 CR4: 00000000001606e0
[ 95.262535] Call Trace:
[ 95.263900] ? xsk_setsockopt+0x153/0x1a0
[ 95.265495] ? __sys_setsockopt+0x67/0xb0
[ 95.267108] ? __x64_sys_setsockopt+0x1b/0x20
[ 95.269532] ? do_syscall_64+0x4f/0x1f0
[ 95.271474] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 95.273292] Modules linked in: pcspkr sg vmw_vmci i2c_piix4 sd_mod ata_generic pata_acpi ahci libahci vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mptspi scsi_transport_spi i2c_core mptscsih e1000 mptbase libata serio_raw
[ 95.279548] CR2: 0000000000000060
[ 95.281044] ---[ end trace 75b6f67917663998 ]---
[ 95.283132] RIP: 0010:xdp_umem_create+0x228/0x3c0
[ 95.285257] Code: f4 ff ff ff e8 b9 f9 ff ff 48 8b bb 90 00 00 00 e8 3d d9 a7 ff 48 c7 83 90 00 00 00 00 00 00 00 48 8b 43 30 8b 93 98 00 00 00 <f0> 48 29 50 60 48 8b 7b 30 49 63 ec e8 57 10 92 ff 48 8b 7b 38 e8
[ 95.291487] RSP: 0018:ffffc900008efe88 EFLAGS: 00010246
[ 95.293429] RAX: 0000000000000000 RBX: ffff880133401288 RCX: 000000000060c0c0
[ 95.295761] RDX: 0000000000200002 RSI: 0000000001000010 RDI: 0000000000000000
[ 95.298072] RBP: 0000000000200002 R08: 0000000000000001 R09: ffffffffffffef81
[ 95.300403] R10: 000000000000000d R11: 0000000000000e8c R12: 00000000fffffff4
[ 95.303699] R13: 0000000000000040 R14: 0000000020000000 R15: 00000000000007c0
[ 95.306178] FS: 00007f8387e61740(0000) GS:ffff88013f4c0000(0000) knlGS:0000000000000000
[ 95.308645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.310782] CR2: 0000000000000060 CR3: 0000000133e2c006 CR4: 00000000001606e0
xdp_umem_create+0x228/0x3c0:
arch_atomic64_sub at arch/x86/include/asm/atomic64_64.h:60
(inlined by) atomic64_sub at include/asm-generic/atomic-instrumented.h:145
(inlined by) atomic_long_sub at include/asm-generic/atomic-long.h:199
(inlined by) xdp_umem_unaccount_pages at net/xdp/xdp_umem.c:135
(inlined by) xdp_umem_reg at net/xdp/xdp_umem.c:334
(inlined by) xdp_umem_create at net/xdp/xdp_umem.c:349
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in sock_poll
From: Tetsuo Handa @ 2018-06-10 1:38 UTC (permalink / raw)
To: syzbot, ubraun, linux-s390; +Cc: davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <00000000000080d9a6056e3aeb35@google.com>
On 2018/06/10 4:57, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1188a05f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
> dashboard link: https://syzkaller.appspot.com/bug?extid=344bb0f46d7719cd9483
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12b5841f800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f4005f800000
This is a same report except s/epoll/poll/ .
----------
#include <sys/socket.h>
#include <sys/poll.h>
#define PF_SMC 43
int main(int argc, char *argv[])
{
int sfd = socket(PF_SMC, SOCK_STREAM, 0);
struct pollfd pfd = { .fd = sfd };
poll(&pfd, 1, 0);
return 0;
}
----------
#syz dup: BUG: unable to handle kernel NULL pointer dereference in corrupted
^ permalink raw reply
* Re: [bug] cxgb4: vrf stopped working with cxgb4 card
From: David Ahern @ 2018-06-10 0:47 UTC (permalink / raw)
To: AMG Zollner Robert, ganeshgr; +Cc: netdev
In-Reply-To: <b515a1c7-2cf8-1af8-372d-393420d298b8@cloudmedia.eu>
Ganesh:
On 6/4/18 9:03 AM, AMG Zollner Robert wrote:
> I have noticed that vrf is not working with kernel v4.15.0 but was
> working with v4.13.0 when using cxgb4 Chelsio driver (T520-cr)
>
> Setup:
> Two metal servers with a T520-cr card each, directly connected without a
> switch in between.
>
> SVR1 only ipfwd SVR2 with vrf
> .----------------------------. .----------------------------------.
> | | | |
> | 192.168.8.1 [ ens2f4]--|---------|--[ens1f4] 192.168.8.2 |
> | 192.168.9.1 [ens2f4d1]--|---------|--<ens1f4d1> 192.168.9.2 VRF=10 |
> `----------------------------' `----------------------------------'
>
> When vrf is not working there are no error messages (dmesg or iproute
> commands), tcpdump on the interface (SVR2.ens1f4d1) enslaved in vrf 10
> shows packets(arp req/reply) coming in and going out, but outgoing
> packets(arp reply) do not reach the other server SVR1.ens2f4d1
>
>
> Bisect:
> Found this commit to be the problem after doing a git bisect between
> v4.13..v4.15:
>
> commit ba581f77df23c8ee70b372966e69cf10bc5453d8
> Author: Ganesh Goudar <ganeshgr@chelsio.com>
> Date: Sat Sep 23 16:07:28 2017 +0530
>
> cxgb4: do DCB state reset in couple of places
>
> reset the driver's DCB state in couple of places
> where it was missing.
Are you working on a fix for this or should a revert of the above patch
be sent?
>
>
> A bisect step was considered good when:
> - successful ping from SVR1 to SVR2.ens1f4d1 vrf interface
> - successful ping from SVR2 global to SVR2 vrf interface trough SVR1(l3
> forwarding) (this check was redundant,both tests fail or pass simultaneous)
>
> The problem is still present on recent kernels also, checked v4.16.0 and
> v4.17.rc7
>
> Disabling DCB for the card support fixes the problem ( Compiling kernel
> with "CONFIG_CHELSIO_T4_DCB=n")
>
>
>
> This is my first time reporting a bug to the linux kernel and hope I
> have included the right amount of information. Please let me know if I
> have missed something.
>
>
>
> Thank you,
> Zollner Robert
>
>
> --------
> Logs:
>
> VRF configured using folowing commands:
>
> #!/bin/sh
>
> CHDEV=ens1f4
> VRF=vrf-recv
>
> sysctl -w net.ipv4.tcp_l3mdev_accept=1
> sysctl -w net.ipv4.udp_l3mdev_accept=1
> sysctl -w net.ipv4.conf.all.accept_local=1
>
> ifconfig ${CHDEV} 192.168.8.2/24
> ifconfig ${CHDEV}d1 192.168.9.2/24
>
> ip link add ${VRF} type vrf table 10
> ip link set dev ${VRF} up
>
> ip rule add pref 32765 table local
> ip rule del pref 0
>
> ip route add table 10 unreachable default metric 4278198272
>
> ip link set dev ${CHDEV}d1 master ${VRF}
>
> ip route add table 10 default via 192.168.9.1
> ip route add 192.168.9.0/24 via 192.168.8.1
>
>
>
>
^ permalink raw reply
* Re: BUG: unable to handle kernel paging request in ebt_do_table
From: Florian Westphal @ 2018-06-09 23:54 UTC (permalink / raw)
To: syzbot; +Cc: netdev, netfilter-devel, syzkaller-bugs
In-Reply-To: <0000000000008fa9d0056e3d4bc9@google.com>
fixed via:
#syz dup: WARNING in ebt_do_table
^ permalink raw reply
* Re: [PATCH v3 net-next] net:sched: add action inheritdsfield to skbedit
From: Marcelo Ricardo Leitner @ 2018-06-09 22:51 UTC (permalink / raw)
To: Fu, Qiaobin
Cc: davem@davemloft.net, netdev@vger.kernel.org, jhs@mojatatu.com,
Michel Machado, xiyou.wangcong@gmail.com
In-Reply-To: <38C2B0E3-E108-433B-906A-A2D72CEE4CAE@bu.edu>
On Sat, Jun 09, 2018 at 10:35:48PM +0000, Fu, Qiaobin wrote:
...
> @@ -73,6 +100,7 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
> struct tc_skbedit *parm;
> struct tcf_skbedit *d;
> u32 flags = 0, *priority = NULL, *mark = NULL, *mask = NULL;
> + u64 *pure_flags = NULL;
> u16 *queue_mapping = NULL, *ptype = NULL;
> bool exists = false;
> int ret = 0, err;
> @@ -114,6 +142,11 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
> mask = nla_data(tb[TCA_SKBEDIT_MASK]);
> }
>
> + if (tb[TCA_SKBEDIT_FLAGS] != NULL) {
> + pure_flags = nla_data(tb[TCA_SKBEDIT_FLAGS]);
> + flags |= *pure_flags;
It shouldn't allow setting flags other than the expected ones.
> + }
> +
> parm = nla_data(tb[TCA_SKBEDIT_PARMS]);
>
> exists = tcf_idr_check(tn, parm->index, a, bind);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox