* Grant Benefit
From: Mrs Julie Leach @ 2016-11-03 6:08 UTC (permalink / raw)
To: Recipients
You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach104@gmail.com) for claims
^ permalink raw reply
* Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)
From: Cong Wang @ 2016-11-03 5:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Johannes Berg, Linux Kernel Network Developers, LKML,
Catalin Marinas, linux-mm
In-Reply-To: <20161102234755.4381f528@jkicinski-Precision-T1700>
On Wed, Nov 2, 2016 at 4:47 PM, Jakub Kicinski <kubakici@wp.pl> wrote:
>
> Thanks for looking into this! Bisect led me to the following commit:
>
> commit 56989f6d8568c21257dcec0f5e644d5570ba3281
> Author: Johannes Berg <johannes.berg@intel.com>
> Date: Mon Oct 24 14:40:05 2016 +0200
>
> genetlink: mark families as __ro_after_init
>
> Now genl_register_family() is the only thing (other than the
> users themselves, perhaps, but I didn't find any doing that)
> writing to the family struct.
>
> In all families that I found, genl_register_family() is only
> called from __init functions (some indirectly, in which case
> I've add __init annotations to clarifly things), so all can
> actually be marked __ro_after_init.
>
> This protects the data structure from accidental corruption.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
> I realized that kmemleak is not scanning the __ro_after_init section...
> Following patch solves the false positives but I wonder if it's the
> right/acceptable solution.
Nice work! Looks reasonable to me, but I am definitely not familiar
with kmemleak. ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla
From: Cong Wang @ 2016-11-03 5:29 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S. Miller, Nicolas Dichtel, LKML, Matti Vaittinen,
Tycho Andersen, stephen hemminger, Tom Herbert, Florian Westphal,
netdev
In-Reply-To: <CAM_iQpWBoEhaLfCYPaStZ-U8s-i5h9fmaG9JCW-q7QfjntfEOA@mail.gmail.com>
On Wed, Nov 2, 2016 at 10:25 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Nov 2, 2016 at 5:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer:
>>
>> ==================================================================
>> BUG: KASAN: global-out-of-bounds in validate_nla+0x49b/0x4e0 at addr
>> ffffffff8407e3ac
>> Read of size 2 by task a.out/3877
>> Address belongs to variable[< none >]
>> cgroupstats_cmd_get_policy+0xc/0x40 ??:?
>
> Seems taskstats doesn't use genetlink correctly, CGROUPSTATS_CMD_ATTR_FD
> is not within 0~TASKSTATS_CMD_ATTR_MAX.
>
> I guess we need the following patch, but it certainly breaks user-space... :-/
Wait, maybe just this one-line fix is enough:
diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index b3f05ee..e6b342e 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -54,7 +54,7 @@ static const struct nla_policy
taskstats_cmd_get_policy[TASKSTATS_CMD_ATTR_MAX+1
[TASKSTATS_CMD_ATTR_REGISTER_CPUMASK] = { .type = NLA_STRING },
[TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK] = { .type = NLA_STRING },};
-static const struct nla_policy
cgroupstats_cmd_get_policy[CGROUPSTATS_CMD_ATTR_MAX+1] = {
+static const struct nla_policy
cgroupstats_cmd_get_policy[TASKSTATS_CMD_ATTR_MAX+1] = {
[CGROUPSTATS_CMD_ATTR_FD] = { .type = NLA_U32 },
};
^ permalink raw reply related
* Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla
From: Cong Wang @ 2016-11-03 5:25 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S. Miller, Nicolas Dichtel, LKML, Matti Vaittinen,
Tycho Andersen, stephen hemminger, Tom Herbert, Florian Westphal,
netdev
In-Reply-To: <CAAeHK+xm5_n-Ep2d4YEq=Yx=f5M2NpV-So0o7811LUk+pLr+rg@mail.gmail.com>
On Wed, Nov 2, 2016 at 5:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> ==================================================================
> BUG: KASAN: global-out-of-bounds in validate_nla+0x49b/0x4e0 at addr
> ffffffff8407e3ac
> Read of size 2 by task a.out/3877
> Address belongs to variable[< none >]
> cgroupstats_cmd_get_policy+0xc/0x40 ??:?
Seems taskstats doesn't use genetlink correctly, CGROUPSTATS_CMD_ATTR_FD
is not within 0~TASKSTATS_CMD_ATTR_MAX.
I guess we need the following patch, but it certainly breaks user-space... :-/
diff --git a/include/uapi/linux/cgroupstats.h b/include/uapi/linux/cgroupstats.h
index 3753c33..b5c120c 100644
--- a/include/uapi/linux/cgroupstats.h
+++ b/include/uapi/linux/cgroupstats.h
@@ -61,7 +61,7 @@ enum {
#define CGROUPSTATS_TYPE_MAX (__CGROUPSTATS_TYPE_MAX - 1)
enum {
- CGROUPSTATS_CMD_ATTR_UNSPEC = 0,
+ CGROUPSTATS_CMD_ATTR_UNSPEC = __TASKSTATS_CMD_ATTR_MAX,
CGROUPSTATS_CMD_ATTR_FD,
__CGROUPSTATS_CMD_ATTR_MAX,
};
diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index b3f05ee..78502b0 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -45,7 +45,7 @@ static struct genl_family family = {
.id = GENL_ID_GENERATE,
.name = TASKSTATS_GENL_NAME,
.version = TASKSTATS_GENL_VERSION,
- .maxattr = TASKSTATS_CMD_ATTR_MAX,
+ .maxattr = CGROUPSTATS_CMD_ATTR_MAX,
};
static const struct nla_policy
taskstats_cmd_get_policy[TASKSTATS_CMD_ATTR_MAX+1] = {
^ permalink raw reply related
* bpf: kernel BUG in htab_elem_free
From: Dmitry Vyukov @ 2016-11-03 5:14 UTC (permalink / raw)
To: Alexei Starovoitov, netdev, Daniel Borkmann; +Cc: LKML, syzkaller
Here we go.
The following program triggers kernel BUG in htab_elem_free.
On commit 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
Run as "while true; do ./a.out; done".
------------[ cut here ]------------
kernel BUG at mm/slub.c:3866!
invalid opcode: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 1 PID: 1542 Comm: kworker/1:2 Not tainted 4.9.0-rc3+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events bpf_map_free_deferred
task: ffff88003b9c0040 task.stack: ffff88003cb70000
RIP: 0010:[<ffffffff814c9f00>] [<ffffffff814c9f00>] kfree+0x140/0x1a0
RSP: 0018:ffff88003cb77c50 EFLAGS: 00010246
RAX: ffffea0000fb0aa0 RBX: ffff88003ec2a1a8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffff10007b50401 RDI: ffff88003ec2a1a8
RBP: ffff88003cb77c70 R08: 0000000000021800 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffea0000fb0a80
R13: ffffffff81392bcb R14: 0000000000000000 R15: ffff88003ec2a1a8
FS: 0000000000000000(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000205d7000 CR3: 0000000037d29000 CR4: 00000000000006e0
Stack:
dffffc0000000000 ffff88003da82008 ffff88003b75bb88 0000000000000000
ffff88003cb77ce0 ffffffff81392bcb ffffffff81acf4f8 ffff88003b75bc04
ffff88003b75bbe0 ffffed00076eb772 ffff88003b75bb90 000000003cb77ce0
Call Trace:
[< inline >] htab_elem_free kernel/bpf/hashtab.c:388
[< inline >] delete_all_elements kernel/bpf/hashtab.c:690
[<ffffffff81392bcb>] htab_map_free+0x30b/0x470 kernel/bpf/hashtab.c:711
[<ffffffff8137e9dc>] bpf_map_free_deferred+0xac/0xd0 kernel/bpf/syscall.c:97
[<ffffffff8114f937>] process_one_work+0x8a7/0x1300 kernel/workqueue.c:2096
[<ffffffff8115047d>] worker_thread+0xed/0x14e0 kernel/workqueue.c:2230
[<ffffffff811619dc>] kthread+0x1ec/0x260 kernel/kthread.c:209
[<ffffffff82fa78c5>] ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:433
Code: 83 c4 18 48 89 da 4c 89 ee ff d0 49 8b 04 24 48 85 c0 75 e6 e9
e9 fe ff ff 49 8b 04 24 f6 c4 40 75 0b 49 8b 44 24 20 a8 01 75 02 <0f>
0b 48 89 df e8 56 35 00 00 49 8b 04 24 31 f6 f6 c4 40 74 05
RIP [< inline >] PageCompound ./include/linux/page-flags.h:157
RIP [<ffffffff814c9f00>] kfree+0x140/0x1a0 mm/slub.c:3866
RSP <ffff88003cb77c50>
---[ end trace 1dc58d6aeb2596aa ]---
==================================================================
BUG: KASAN: stack-out-of-bounds in complete+0x68/0x70 at addr ffff88003cb77ed8
Read of size 4 by task kworker/1:2/1542
page:ffffea0000f2ddc0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x100000000000000()
page dumped because: kasan: bad access detected
CPU: 1 PID: 1542 Comm: kworker/1:2 Tainted: G D 4.9.0-rc3+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88003cb77ce0 ffffffff81acf609 ffffed000796efdb ffffed000796efdb
0000000000000004 0000000000000000 ffff88003cb77d60 ffffffff814cdbfb
ffff88003c8d97c8 dffffc0000000000 ffffffff811dd038 0000000000000097
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81acf609>] dump_stack+0x83/0xba lib/dump_stack.c:51
[< inline >] kasan_report_error mm/kasan/report.c:204
[<ffffffff814cdbfb>] kasan_report+0x4cb/0x500 mm/kasan/report.c:303
[<ffffffff814cdc84>] __asan_report_load4_noabort+0x14/0x20
mm/kasan/report.c:328
[<ffffffff811dd038>] complete+0x68/0x70 kernel/sched/completion.c:34
[< inline >] complete_vfork_done kernel/fork.c:1030
[<ffffffff810fa8c2>] mm_release+0x222/0x3f0 kernel/fork.c:1114
[< inline >] exit_mm kernel/exit.c:467
[<ffffffff8110b501>] do_exit+0x3a1/0x2960 kernel/exit.c:815
[<ffffffff82fa8b97>] rewind_stack_do_exit+0x17/0x20
arch/x86/entry/entry_64.S:1526
Memory state around the buggy address:
ffff88003cb77d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88003cb77e00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4
>ffff88003cb77e80: f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4
^
ffff88003cb77f00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
ffff88003cb77f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
BUG: unable to handle kernel
paging request at ffffffffffffffd8
IP: [<ffffffff81163c5d>] kthread_data+0x4d/0x70 kernel/kthread.c:137
PGD 360d067 [ 48.581115] PUD 360f067
PMD 0 [ 48.581840]
Oops: 0000 [#2] SMP KASAN
Modules linked in:
CPU: 1 PID: 1542 Comm: kworker/1:2 Tainted: G B D 4.9.0-rc3+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88003b9c0040 task.stack: ffff88003cb70000
RIP: 0010:[<ffffffff81163c5d>] [<ffffffff81163c5d>] kthread_data+0x4d/0x70
RSP: 0018:ffff88003cb77c78 EFLAGS: 00010046
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 1ffffffffffffffb RSI: ffff88003b9c00c0 RDI: ffffffffffffffd8
RBP: ffff88003cb77c80 R08: ffff88003ed20a48 R09: ffff88003ed20a40
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003ed20980
R13: ffff88003b9c0040 R14: ffff88003b9c0094 R15: 0000000000000040
FS: 0000000000000000(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 000000000360c000 CR4: 00000000000006e0
Stack:
ffff88003b9c0040 ffff88003cb77ca0 ffffffff81155e77 0000000000020980
ffff88003ed20980 ffff88003cb77db8 ffffffff82f9b1a2 0000000000000000
ffff88003ddd2670 00ff88003ddd2640 ffff88003ed211f8 1ffff1000796ef9e
Call Trace:
[<ffffffff81155e77>] wq_worker_sleeping+0x17/0x210 kernel/workqueue.c:876
[<ffffffff82f9b1a2>] __schedule+0xc62/0x1730 kernel/sched/core.c:3380
[<ffffffff8118c781>] do_task_dead+0x81/0xa0 kernel/sched/core.c:3431
[<ffffffff8110c7f8>] do_exit+0x1698/0x2960 kernel/exit.c:885
[<ffffffff82fa8b97>] rewind_stack_do_exit+0x17/0x20
arch/x86/entry/entry_64.S:1526
Code: c1 ea 03 80 3c 02 00 75 29 48 8b 9b 30 05 00 00 48 b8 00 00 00
00 00 fc ff df 48 8d 7b d8 48 89 fa 48 c1 ea 03 80 3c 02 00 75 0e <48>
8b 43 d8 5b 5d c3 e8 27 a0 36 00 eb d0 e8 20 a0 36 00 eb eb
RIP [<ffffffff81163c5d>] kthread_data+0x4d/0x70 kernel/kthread.c:137
RSP <ffff88003cb77c78>
CR2: ffffffffffffffd8
---[ end trace 1dc58d6aeb2596ab ]---
Fixing recursive fault but reboot is needed!
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_bpf
#define __NR_bpf 321
#endif
#include <fcntl.h>
#include <pthread.h>
#include <signal.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
long r[14];
void* thr(void* arg)
{
switch ((long)arg) {
case 0:
r[0] =
syscall(__NR_mmap, 0x20000000ul, 0x16000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
break;
case 1:
(*(uint32_t*)0x20011000 = (uint32_t)0x1);
(*(uint32_t*)0x20011004 = (uint32_t)0x8);
(*(uint32_t*)0x20011008 = (uint32_t)0x3);
(*(uint32_t*)0x2001100c = (uint32_t)0x1);
(*(uint32_t*)0x20011010 = (uint32_t)0x1);
r[6] = syscall(__NR_bpf, 0x0ul, 0x20011000ul, 0x14ul, 0, 0,
0, 0, 0, 0);
break;
case 2:
(*(uint32_t*)0x20013000 = r[6]);
(*(uint64_t*)0x20013008 = (uint64_t)0x20013fb3);
(*(uint64_t*)0x20013010 = (uint64_t)0x20012ff1);
(*(uint64_t*)0x20013018 = (uint64_t)0x0);
(memcpy(
(void*)0x20013fb3,
"\x3e\x51\x32\xbe\xd5\x24\x20\xb2\x50\x7a\x4d\xb5\xec\xb3\x8f"
"\x65\x7f\xac\x61\x9a\xf0\x29\x3f\x77\x07\x2f\x2f\x60\xe9\x78"
"\xc5\x79\x45\x16\x67\xf6\x64\xb4\xd5\xb2\x11\x88\x5f\x4f\x32"
"\xba\xa8\x80\x8f\x7a\xea\x01\x1d\xe4\x08\xa4\x65\x73\x07\x91"
"\x48\xd5\xc3\xf2\xc4\x08\x29\x8f\x88\x95\xc3\xd5\xf6\x86\x0f"
"\x42\xab\x05\xf7\xfa\x2b\x12\x78\xb3\x4d\x17\x8c\x27\x57\x8b"
"\x79\xdc\x4f\x8a\x7a\xf5\x8c\x8a\xc2\x18\x03\xa0\xf9\x5f\x7a",
105));
(memcpy(
(void*)0x20012ff1,
"\xb1\xb0\x4b\x14\x9e\xfa\xbc\xb2\xaf\x4b\x4a\x02\xbc\x9b\xc5",
15));
r[13] = syscall(__NR_bpf, 0x2ul, 0x20013000ul, 0x20ul, 0, 0,
0, 0, 0, 0);
break;
}
return 0;
}
int main()
{
long i;
pthread_t th[6];
memset(r, -1, sizeof(r));
srand(getpid());
for (i = 0; i < 3; i++) {
pthread_create(&th[i], 0, thr, (void*)i);
usleep(10000);
}
for (i = 0; i < 3; i++) {
pthread_create(&th[3 + i], 0, thr, (void*)i);
if (rand() % 2)
usleep(rand() % 10000);
}
usleep(100000);
return 0;
}
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Michael S. Tsirkin @ 2016-11-03 4:11 UTC (permalink / raw)
To: Shrijeet Mukherjee
Cc: Jesper Dangaard Brouer, Thomas Graf, Alexei Starovoitov,
Jakub Kicinski, John Fastabend, David Miller, alexander.duyck,
shrijeet, tom, netdev, Roopa Prabhu, Nikolay Aleksandrov
In-Reply-To: <b09333565b4ead1f90719cfb3643f6af@mail.gmail.com>
On Wed, Nov 02, 2016 at 06:28:34PM -0700, Shrijeet Mukherjee wrote:
> > -----Original Message-----
> > From: Jesper Dangaard Brouer [mailto:brouer@redhat.com]
> > Sent: Wednesday, November 2, 2016 7:27 AM
> > To: Thomas Graf <tgraf@suug.ch>
> > Cc: Shrijeet Mukherjee <shm@cumulusnetworks.com>; Alexei Starovoitov
> > <alexei.starovoitov@gmail.com>; Jakub Kicinski <kubakici@wp.pl>; John
> > Fastabend <john.fastabend@gmail.com>; David Miller
> > <davem@davemloft.net>; alexander.duyck@gmail.com; mst@redhat.com;
> > shrijeet@gmail.com; tom@herbertland.com; netdev@vger.kernel.org;
> > Roopa Prabhu <roopa@cumulusnetworks.com>; Nikolay Aleksandrov
> > <nikolay@cumulusnetworks.com>; brouer@redhat.com
> > Subject: Re: [PATCH net-next RFC WIP] Patch for XDP support for
> virtio_net
> >
> > On Sat, 29 Oct 2016 13:25:14 +0200
> > Thomas Graf <tgraf@suug.ch> wrote:
> >
> > > On 10/28/16 at 08:51pm, Shrijeet Mukherjee wrote:
> > > > Generally agree, but SRIOV nics with multiple queues can end up in a
> > > > bad spot if each buffer was 4K right ? I see a specific page pool to
> > > > be used by queues which are enabled for XDP as the easiest to swing
> > > > solution that way the memory overhead can be restricted to enabled
> > > > queues and shared access issues can be restricted to skb's using
> that
> > pool no ?
> >
> > Yes, that is why that I've been arguing so strongly for having the
> flexibility to
> > attach a XDP program per RX queue, as this only change the memory model
> > for this one queue.
> >
> >
> > > Isn't this clearly a must anyway? I may be missing something
> > > fundamental here so please enlighten me :-)
> > >
> > > If we dedicate a page per packet, that could translate to 14M*4K worth
> > > of memory being mapped per second for just a 10G NIC under DoS attack.
> > > How can one protect such as system? Is the assumption that we can
> > > always drop such packets quickly enough before we start dropping
> > > randomly due to memory pressure? If a handshake is required to
> > > determine validity of a packet then that is going to be difficult.
> >
> > Under DoS attacks you don't run out of memory, because a diverse set of
> > socket memory limits/accounting avoids that situation. What does happen
> > is the maximum achievable PPS rate is directly dependent on the
> > time you spend on each packet. This use of CPU resources (and
> > hitting mem-limits-safe-guards) push-back on the drivers speed to
> process
> > the RX ring. In effect, packets are dropped in the NIC HW as RX-ring
> queue
> > is not emptied fast-enough.
> >
> > Given you don't control what HW drops, the attacker will "successfully"
> > cause your good traffic to be among the dropped packets.
> >
> > This is where XDP change the picture. If you can express (by eBPF) a
> filter
> > that can separate "bad" vs "good" traffic, then you can take back
> control.
> > Almost like controlling what traffic the HW should drop.
> > Given the cost of XDP-eBPF filter + serving regular traffic does not use
> all of
> > your CPU resources, you have overcome the attack.
> >
> > --
> Jesper, John et al .. to make this a little concrete I am going to spin
> up a v2 which has only bigbuffers mode enabled for xdp acceleration, all
> other modes will reject the xdp ndo ..
>
> Do we have agreement on that model ?
>
> It will need that all vhost implementations will need to start with
> mergeable buffers disabled to get xdp goodness, but that sounds like a
> safe thing to do for now ..
It's ok for experimentation, but really after speaking with Alexei it's
clear to me that xdp should have a separate code path in the driver,
e.g. the separation between modes is something that does not
make sense for xdp.
The way I imagine it working:
- when XDP is attached disable all LRO using VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
(not used by driver so far, designed to allow dynamic LRO control with
ethtool)
- start adding page-sized buffers
- do something with non-page-sized buffers added previously - what
exactly? copy I guess? What about LRO packets that are too large -
can we drop or can we split them up?
I'm fine with disabling XDP for some configurations as the first step,
and we can add that support later.
Ideas about mergeable buffers (optional):
At the moment mergeable buffers can't be disabled dynamically.
They do bring a small benefit for XDP if host MTU is large (see below)
and aren't hard to support:
- if header is by itself skip 1st page
- otherwise copy all data into first page
and it's nicer not to add random limitations that require guest reboot.
It might make sense to add a command that disables/enabled
mergeable buffers dynamically but that's for newer hosts.
Spec does not require it but in practice most hosts put all data
in the 1st page or all in the 2nd page so the copy will be nop
for these cases.
Large host MTU - newer hosts report the host MTU, older ones don't.
Using mergeable buffers we can at least detect this case
(and then what? drop I guess).
--
MST
^ permalink raw reply
* (unknown),
From: Mr Friedrich Mayrhofer @ 2016-11-03 3:06 UTC (permalink / raw)
Good Day,
This is the second time i am sending you this mail.
I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.
Regards.
Friedrich Mayrhofer
^ permalink raw reply
* [PATCH net] ipv6: dccp: fix out of bound access in dccp_v6_err()
From: Eric Dumazet @ 2016-11-03 3:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Gerrit Renker, dccp
In-Reply-To: <1478138440.7065.419.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
dccp_v6_err() does not use pskb_may_pull() and might access garbage.
We only need 4 bytes at the beginning of the DCCP header, like TCP,
so the 8 bytes pulled in icmpv6_notify() are more than enough.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/dccp/ipv6.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 3828f94b234c..3d35277a0b41 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -70,7 +70,7 @@ static void dccp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
u8 type, u8 code, int offset, __be32 info)
{
const struct ipv6hdr *hdr = (const struct ipv6hdr *)skb->data;
- const struct dccp_hdr *dh = (struct dccp_hdr *)(skb->data + offset);
+ const struct dccp_hdr *dh;
struct dccp_sock *dp;
struct ipv6_pinfo *np;
struct sock *sk;
@@ -78,12 +78,13 @@ static void dccp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
__u64 seq;
struct net *net = dev_net(skb->dev);
- if (skb->len < offset + sizeof(*dh) ||
- skb->len < offset + __dccp_basic_hdr_len(dh)) {
- __ICMP6_INC_STATS(net, __in6_dev_get(skb->dev),
- ICMP6_MIB_INERRORS);
- return;
- }
+ /* Only need dccph_dport & dccph_sport which are the first
+ * 4 bytes in dccp header.
+ * Our caller (icmpv6_notify()) already pulled 8 bytes for us.
+ */
+ BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_sport) > 8);
+ BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_dport) > 8);
+ dh = (struct dccp_hdr *)(skb->data + offset);
sk = __inet6_lookup_established(net, &dccp_hashinfo,
&hdr->daddr, dh->dccph_dport,
^ permalink raw reply related
* [PATCH net] netlink: netlink_diag_dump() runs without locks
From: Eric Dumazet @ 2016-11-03 3:21 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Herbert Xu, Andrew Morton, David Decotigny, David S. Miller,
Dmitry Ivanov, Eric Dumazet, Florian Westphal, Greg Rose,
Johannes Berg, Matti Vaittinen, Pravin B Shelar,
stephen hemminger, Tom Herbert, Tycho Andersen, LKML, netdev,
syzkaller, Kostya Serebryany, Alexander Potapenko
In-Reply-To: <CAAeHK+xUFKMfW4WoYgyjJeYJZm_gAg3Nr3S0+8M-5H+6a=RVKw@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
A recent commit removed locking from netlink_diag_dump() but forgot
one error case.
=====================================
[ BUG: bad unlock balance detected! ]
4.9.0-rc3+ #336 Not tainted
-------------------------------------
syz-executor/4018 is trying to release lock ([ 36.220068] nl_table_lock
) at:
[<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
but there are no more locks to release!
other info that might help us debug this:
3 locks held by syz-executor/4018:
#0: [ 36.220068] (
sock_diag_mutex[ 36.220068] ){+.+.+.}
, at: [ 36.220068] [<ffffffff82c3873b>] sock_diag_rcv+0x1b/0x40
#1: [ 36.220068] (
sock_diag_table_mutex[ 36.220068] ){+.+.+.}
, at: [ 36.220068] [<ffffffff82c38e00>] sock_diag_rcv_msg+0x140/0x3a0
#2: [ 36.220068] (
nlk->cb_mutex[ 36.220068] ){+.+.+.}
, at: [ 36.220068] [<ffffffff82db6600>] netlink_dump+0x50/0xac0
stack backtrace:
CPU: 1 PID: 4018 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff8800645df688 ffffffff81b46934 ffffffff84eb3e78 ffff88006ad85800
ffffffff82dc8683 ffffffff84eb3e78 ffff8800645df6b8 ffffffff812043ca
dffffc0000000000 ffff88006ad85ff8 ffff88006ad85fd0 00000000ffffffff
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff812043ca>] print_unlock_imbalance_bug+0x17a/0x1a0
kernel/locking/lockdep.c:3388
[< inline >] __lock_release kernel/locking/lockdep.c:3512
[<ffffffff8120cfd8>] lock_release+0x8e8/0xc60 kernel/locking/lockdep.c:3765
[< inline >] __raw_read_unlock ./include/linux/rwlock_api_smp.h:225
[<ffffffff83fc001a>] _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
[<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
[<ffffffff82db6947>] netlink_dump+0x397/0xac0 net/netlink/af_netlink.c:2110
Fixes: ad202074320c ("netlink: Use rhashtable walk interface in diag dump")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
---
net/netlink/diag.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/netlink/diag.c b/net/netlink/diag.c
index b2f0e986a6f4..a5546249fb10 100644
--- a/net/netlink/diag.c
+++ b/net/netlink/diag.c
@@ -178,11 +178,8 @@ static int netlink_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
}
cb->args[1] = i;
} else {
- if (req->sdiag_protocol >= MAX_LINKS) {
- read_unlock(&nl_table_lock);
- rcu_read_unlock();
+ if (req->sdiag_protocol >= MAX_LINKS)
return -ENOENT;
- }
err = __netlink_diag_dump(skb, cb, req->sdiag_protocol, s_num);
}
^ permalink raw reply related
* Re: net/netlink: null-ptr-deref in netlink_dump/lock_acquire
From: Andrey Konovalov @ 2016-11-03 3:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Herbert Xu, Andrew Morton, David Decotigny, David S. Miller,
Dmitry Ivanov, Eric Dumazet, Florian Westphal, Greg Rose,
Johannes Berg, Matti Vaittinen, Pravin B Shelar,
stephen hemminger, Tom Herbert, Tycho Andersen, LKML, netdev,
syzkaller, Kostya Serebryany, Alexander Potapenko
In-Reply-To: <1478141906.7065.421.camel@edumazet-glaptop3.roam.corp.google.com>
Hi Eric,
This fixes the second report, the first one is still there.
Apparently these are two separate issues.
For the second one:
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Thanks for the fix!
On Thu, Nov 3, 2016 at 3:58 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2016-11-03 at 03:36 +0100, Andrey Konovalov wrote:
>> On Thu, Nov 3, 2016 at 1:15 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > On Wed, Oct 19, 2016 at 4:13 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> >> Hi,
>> >>
>> >> I've got the following error report while running the syzkaller fuzzer:
>> >>
>> >> kasan: CONFIG_KASAN_INLINE enabled
>> >> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> >> general protection fault: 0000 [#1] SMP KASAN
>> >> Modules linked in:
>> >> CPU: 1 PID: 3933 Comm: syz-executor Not tainted 4.9.0-rc1+ #230
>> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> >> task: ffff88006b79d800 task.stack: ffff88006bbc0000
>> >> RIP: 0010:[<ffffffff8120872d>] [<ffffffff8120872d>]
>> >> __lock_acquire+0x12d/0x3450 kernel/locking/lockdep.c:3221
>> >> RSP: 0018:ffff88006bbc7420 EFLAGS: 00010006
>> >> RAX: 0000000000000046 RBX: dffffc0000000000 RCX: 0000000000000000
>> >> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000003
>> >> RBP: ffff88006bbc75c0 R08: 0000000000000001 R09: 0000000000000000
>> >> R10: 0000000000000000 R11: ffffffff85f42240 R12: ffff88006b79d800
>> >> R13: ffffffff84bfe4e0 R14: 0000000000000001 R15: 0000000000000060
>> >> FS: 00007fd9c41cc700(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
>> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> >> CR2: 0000000000451f80 CR3: 00000000638f0000 CR4: 00000000000006e0
>> >> Stack:
>> >> 0000000000000000 ffff88006bbc0000 ffff88006bbc8000 0000000000000000
>> >> 0000000000000002 ffff88006b79d800 0000000000000000 ffff88006bbc7f48
>> >> ffffffff852adc60 0000000000000000 ffffffff852adc64 1ffffffff0b40135
>> >> Call Trace:
>> >> [<ffffffff8120c5ae>] lock_acquire+0x17e/0x340 kernel/locking/lockdep.c:3746
>> >> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
>> >> [<ffffffff83fb6fe1>] mutex_lock_nested+0xb1/0x890 kernel/locking/mutex.c:621
>> >> [<ffffffff82db6fd0>] netlink_dump+0x50/0xac0 net/netlink/af_netlink.c:2067
>> >> [<ffffffff82dba381>] __netlink_dump_start+0x501/0x770
>> >> net/netlink/af_netlink.c:2200
>> >> [<ffffffff82dc35b2>] genl_family_rcv_msg+0xa02/0xc80
>> >> net/netlink/genetlink.c:595
>> >> [<ffffffff82dc39e6>] genl_rcv_msg+0x1b6/0x270 net/netlink/genetlink.c:658
>> >> [<ffffffff82dc1a70>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
>> >> [<ffffffff82dc2b98>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:669
>> >> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
>> >> [<ffffffff82dc0329>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
>> >> [<ffffffff82dc0fb7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
>> >> [< inline >] sock_sendmsg_nosec net/socket.c:606
>> >> [<ffffffff82b7075c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
>> >> [<ffffffff82b709c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
>> >> [< inline >] new_sync_write fs/read_write.c:499
>> >> [<ffffffff8151c944>] __vfs_write+0x334/0x570 fs/read_write.c:512
>> >> [<ffffffff8152045b>] vfs_write+0x17b/0x500 fs/read_write.c:560
>> >> [< inline >] SYSC_write fs/read_write.c:607
>> >> [<ffffffff81523d84>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
>> >> [<ffffffff83fc0141>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> >> arch/x86/entry/entry_64.S:209
>> >> Code: 0f 1f 44 00 00 f6 c4 02 0f 85 24 0a 00 00 44 8b 35 c9 61 8b 03
>> >> 45 85 f6 74 2c 4c 89 fa 48 bb 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
>> >> 3c 1a 00 0f 85 04 2f 00 00 49 81 3f a0 dc 2a 85 41 be 00 00
>> >> RIP [<ffffffff8120872d>] __lock_acquire+0x12d/0x3450
>> >> kernel/locking/lockdep.c:3221
>> >> RSP <ffff88006bbc7420>
>> >> ---[ end trace 685b3c182bf7f25c ]---
>> >>
>> >> The reproducer is attached.
>> >>
>> >> On commit 1a1891d762d6e64daf07b5be4817e3fbb29e3c59 (Oct 18).
>> >
>> > (Adding more maintainers)
>> >
>> > Still seeing this on 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
>>
>> Here is another report that might be related:
>>
>> =====================================
>> [ BUG: bad unlock balance detected! ]
>> 4.9.0-rc3+ #336 Not tainted
>> -------------------------------------
>> syz-executor/4018 is trying to release lock ([ 36.220068] nl_table_lock
>> ) at:
>> [<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
>> but there are no more locks to release!
>>
>> other info that might help us debug this:
>> 3 locks held by syz-executor/4018:
>> #0: [ 36.220068] (
>> sock_diag_mutex[ 36.220068] ){+.+.+.}
>> , at: [ 36.220068] [<ffffffff82c3873b>] sock_diag_rcv+0x1b/0x40
>> #1: [ 36.220068] (
>> sock_diag_table_mutex[ 36.220068] ){+.+.+.}
>> , at: [ 36.220068] [<ffffffff82c38e00>] sock_diag_rcv_msg+0x140/0x3a0
>> #2: [ 36.220068] (
>> nlk->cb_mutex[ 36.220068] ){+.+.+.}
>> , at: [ 36.220068] [<ffffffff82db6600>] netlink_dump+0x50/0xac0
>>
>> stack backtrace:
>> CPU: 1 PID: 4018 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800645df688 ffffffff81b46934 ffffffff84eb3e78 ffff88006ad85800
>> ffffffff82dc8683 ffffffff84eb3e78 ffff8800645df6b8 ffffffff812043ca
>> dffffc0000000000 ffff88006ad85ff8 ffff88006ad85fd0 00000000ffffffff
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff812043ca>] print_unlock_imbalance_bug+0x17a/0x1a0
>> kernel/locking/lockdep.c:3388
>> [< inline >] __lock_release kernel/locking/lockdep.c:3512
>> [<ffffffff8120cfd8>] lock_release+0x8e8/0xc60 kernel/locking/lockdep.c:3765
>> [< inline >] __raw_read_unlock ./include/linux/rwlock_api_smp.h:225
>> [<ffffffff83fc001a>] _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
>> [<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
>> [<ffffffff82db6947>] netlink_dump+0x397/0xac0 net/netlink/af_netlink.c:2110
>> [<ffffffff82db99b1>] __netlink_dump_start+0x501/0x770
>> net/netlink/af_netlink.c:2200
>> [< inline >] netlink_dump_start ./include/linux/netlink.h:165
>> [<ffffffff82dc75d1>] netlink_diag_handler_dump+0x191/0x220
>> net/netlink/diag.c:218
>> [< inline >] __sock_diag_cmd net/core/sock_diag.c:239
>> [<ffffffff82c38fd6>] sock_diag_rcv_msg+0x316/0x3a0 net/core/sock_diag.c:270
>> [<ffffffff82dc10a0>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
>> [<ffffffff82c3874a>] sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:281
>> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
>> [<ffffffff82dbf959>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
>> [<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
>> [< inline >] sock_sendmsg_nosec net/socket.c:606
>> [<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
>> [<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
>> [< inline >] new_sync_write fs/read_write.c:499
>> [<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
>> [<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
>> [< inline >] SYSC_write fs/read_write.c:607
>> [<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
>> [<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> ------------[ cut here ]------------
>> WARNING: CPU: 1 PID: 4018 at net/core/skbuff.c:654[< none
>> >] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
>> Modules linked in:
>> CPU: 1 PID: 4018 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800645df920 ffffffff81b46934 0000000000000000 0000000000000000
>> ffffffff84401fa0 0000000000000000 ffff8800645df968 ffffffff811112f7
>> ffffffff83fb92f2 ffff88000000028e ffffffff84401fa0 000000000000028e
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff811112f7>] __warn+0x1a7/0x1f0 kernel/panic.c:550
>> [<ffffffff8111150c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
>> [<ffffffff82b885ea>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
>> [<ffffffff82b91815>] skb_release_all+0x15/0x60 net/core/skbuff.c:668
>> [< inline >] __kfree_skb net/core/skbuff.c:684
>> [<ffffffff82ba0175>] consume_skb+0x115/0x2e0 net/core/skbuff.c:757
>> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1215
>> [<ffffffff82dbf961>] netlink_unicast+0x5b1/0x880 net/netlink/af_netlink.c:1240
>> [<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
>> [< inline >] sock_sendmsg_nosec net/socket.c:606
>> [<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
>> [<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
>> [< inline >] new_sync_write fs/read_write.c:499
>> [<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
>> [<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
>> [< inline >] SYSC_write fs/read_write.c:607
>> [<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
>> [<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> ---[ end trace bb9fa7cf182d59a5 ]---
>> BUG: scheduling while atomic: syz-executor/4018/0x7fffffff
>> INFO: lockdep is turned off.
>> Modules linked in:
>> CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800645dfe28 ffffffff81b46934 dffffc0000000000 000000007fffffff
>> 00000000000214c0 0000000000000001 ffff8800645dfe48 ffffffff8119113a
>> ffff88006cd214c0 0000000000000000 ffff8800645dfec8 ffffffff83fb030a
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff8119113a>] __schedule_bug+0xfa/0x140 kernel/sched/core.c:3230
>> [< inline >] schedule_debug kernel/sched/core.c:3245
>> [<ffffffff83fb030a>] __schedule+0xfda/0x1ab0 kernel/sched/core.c:3345
>> [<ffffffff83fb0e70>] schedule+0x90/0x1b0 kernel/sched/core.c:3457
>> [<ffffffff810039e9>] exit_to_usermode_loop+0xc9/0x130
>> arch/x86/entry/common.c:149
>> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>> [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
>> arch/x86/entry/common.c:259
>> [<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
>> arch/x86/entry/entry_64.S:244
>> NOHZ: local_softirq_pending 202
>> ------------[ cut here ]------------
>> WARNING: CPU: 1 PID: 4018 at net/core/skbuff.c:654[< none
>> >] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
>> Modules linked in:[ 36.328353] CPU: 1 PID: 4018 Comm: syz-executor
>> Tainted: G W 4.9.0-rc3+ #336
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800645df920 ffffffff81b46934 0000000000000000 0000000000000000
>> ffffffff84401fa0 0000000000000000 ffff8800645df968 ffffffff811112f7
>> ffffffff83fb92f2 ffff88000000028e ffffffff84401fa0 000000000000028e
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff811112f7>] __warn+0x1a7/0x1f0 kernel/panic.c:550
>> [<ffffffff8111150c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
>> [<ffffffff82b885ea>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
>> [<ffffffff82b91815>] skb_release_all+0x15/0x60 net/core/skbuff.c:668
>> [< inline >] __kfree_skb net/core/skbuff.c:684
>> [<ffffffff82ba0175>] consume_skb+0x115/0x2e0 net/core/skbuff.c:757
>> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1215
>> [<ffffffff82dbf961>] netlink_unicast+0x5b1/0x880 net/netlink/af_netlink.c:1240
>> [<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
>> [< inline >] sock_sendmsg_nosec net/socket.c:606
>> [<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
>> [<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
>> [< inline >] new_sync_write fs/read_write.c:499
>> [<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
>> [<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
>> [< inline >] SYSC_write fs/read_write.c:607
>> [<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
>> [<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> ---[ end trace bb9fa7cf182d59a6 ]---
>> BUG: sleeping function called from invalid context at
>> ./include/linux/freezer.h:56
>> in_atomic(): 1, irqs_disabled(): 0, pid: 4018, name: syz-executor
>> INFO: lockdep is turned off.
>> CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800645dfbb0 ffffffff81b46934 ffff88006ad85800 ffff8800645d8000
>> ffff88006ad85800 0000000000000000 ffff8800645dfbd8 ffffffff81192131
>> ffff88006ad85800 ffffffff8404c140 0000000000000038 ffff8800645dfc18
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff81192131>] ___might_sleep+0x281/0x3c0 kernel/sched/core.c:7767
>> [<ffffffff81192306>] __might_sleep+0x96/0x1a0 kernel/sched/core.c:7726
>> [< inline >] try_to_freeze_unsafe ./include/linux/freezer.h:56
>> [< inline >] try_to_freeze ./include/linux/freezer.h:66
>> [<ffffffff81143849>] get_signal+0x129/0x15a0 kernel/signal.c:2147
>> [<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
>> [<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
>> arch/x86/entry/common.c:156
>> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>> [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
>> arch/x86/entry/common.c:259
>> [<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
>> arch/x86/entry/entry_64.S:244
>> Kernel panic - not syncing: Aiee, killing interrupt handler!
>> CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800645df998 ffffffff81b46934 0000000000000003 dffffc0000000000
>> dffffc0000000000 ffff8800645dfa04 ffff8800645dfa60 ffffffff8140bf7a
>> 0000000041b58ab3 ffffffff84797a7d ffffffff8140bdbe ffffffff00000000
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff8140bf7a>] panic+0x1bc/0x39d kernel/panic.c:179
>> [<ffffffff8111cfd8>] do_exit+0x1b48/0x2ac0 kernel/exit.c:740
>> [<ffffffff811222be>] do_group_exit+0x10e/0x340 kernel/exit.c:931
>> [<ffffffff81143d54>] get_signal+0x634/0x15a0 kernel/signal.c:2307
>> [<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
>> [<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
>> arch/x86/entry/common.c:156
>> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>> [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
>> arch/x86/entry/common.c:259
>> [<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
>> arch/x86/entry/entry_64.S:244
>> Kernel Offset: disabled
>> ---[ end Kernel panic - not syncing: Aiee, killing interrupt handler!
>
>
> This is probably a leftover after commit
> ad202074320cd75b31b8cdb58cca0d4ef6aaea8a
> ("netlink: Use rhashtable walk interface in diag dump")
>
> Please try this trivial fix :
>
> diff --git a/net/netlink/diag.c b/net/netlink/diag.c
> index b2f0e986a6f4..a5546249fb10 100644
> --- a/net/netlink/diag.c
> +++ b/net/netlink/diag.c
> @@ -178,11 +178,8 @@ static int netlink_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
> }
> cb->args[1] = i;
> } else {
> - if (req->sdiag_protocol >= MAX_LINKS) {
> - read_unlock(&nl_table_lock);
> - rcu_read_unlock();
> + if (req->sdiag_protocol >= MAX_LINKS)
> return -ENOENT;
> - }
>
> err = __netlink_diag_dump(skb, cb, req->sdiag_protocol, s_num);
> }
>
>
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: David Miller @ 2016-11-03 2:58 UTC (permalink / raw)
To: Larry.Finger
Cc: john, Jes.Sorensen, kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <10e32bb4-fe16-6a0f-eaf4-1142c23e7b56@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Wed, 2 Nov 2016 20:00:03 -0500
> On 10/30/2016 05:21 AM, John Heenan wrote:
>> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to
>> set
>> macpower, is never 0xea. It is only ever 0x01 (first time after
>> modprobe)
>> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These
>> results
>> occurs with 'Fix for authentication failure' [PATCH 1/2] in place.
>>
>> Whatever was returned, code tests always showed that at least
>> rtl8xxxu_init_queue_reserved_page(priv);
>> is always required. Not called if macpower set to true.
>>
>> Please see cover letter, [PATCH 0/2], for more information from tests.
>
> That cover letter will NOT be included in the commit message, thus
> referring to it here is totally pointless.
This is why when a patch series is added to GIT, the cover letter
must be added to the merge commit that adds that series.
It is therefore perfectly valid to refer to such text from a
commit contained by that merge commit.
^ permalink raw reply
* Re: net/netlink: null-ptr-deref in netlink_dump/lock_acquire
From: Eric Dumazet @ 2016-11-03 2:58 UTC (permalink / raw)
To: Andrey Konovalov, Herbert Xu
Cc: Andrew Morton, David Decotigny, David S. Miller, Dmitry Ivanov,
Eric Dumazet, Florian Westphal, Greg Rose, Herbert Xu,
Johannes Berg, Matti Vaittinen, Pravin B Shelar,
stephen hemminger, Tom Herbert, Tycho Andersen, LKML, netdev,
syzkaller, Kostya Serebryany, Alexander Potapenko
In-Reply-To: <CAAeHK+y_1CuCCMDz+sbwS0zG=G9tWvfcFunqgmY8UtR_D=xMww@mail.gmail.com>
On Thu, 2016-11-03 at 03:36 +0100, Andrey Konovalov wrote:
> On Thu, Nov 3, 2016 at 1:15 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Oct 19, 2016 at 4:13 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >> Hi,
> >>
> >> I've got the following error report while running the syzkaller fuzzer:
> >>
> >> kasan: CONFIG_KASAN_INLINE enabled
> >> kasan: GPF could be caused by NULL-ptr deref or user memory access
> >> general protection fault: 0000 [#1] SMP KASAN
> >> Modules linked in:
> >> CPU: 1 PID: 3933 Comm: syz-executor Not tainted 4.9.0-rc1+ #230
> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >> task: ffff88006b79d800 task.stack: ffff88006bbc0000
> >> RIP: 0010:[<ffffffff8120872d>] [<ffffffff8120872d>]
> >> __lock_acquire+0x12d/0x3450 kernel/locking/lockdep.c:3221
> >> RSP: 0018:ffff88006bbc7420 EFLAGS: 00010006
> >> RAX: 0000000000000046 RBX: dffffc0000000000 RCX: 0000000000000000
> >> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000003
> >> RBP: ffff88006bbc75c0 R08: 0000000000000001 R09: 0000000000000000
> >> R10: 0000000000000000 R11: ffffffff85f42240 R12: ffff88006b79d800
> >> R13: ffffffff84bfe4e0 R14: 0000000000000001 R15: 0000000000000060
> >> FS: 00007fd9c41cc700(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> CR2: 0000000000451f80 CR3: 00000000638f0000 CR4: 00000000000006e0
> >> Stack:
> >> 0000000000000000 ffff88006bbc0000 ffff88006bbc8000 0000000000000000
> >> 0000000000000002 ffff88006b79d800 0000000000000000 ffff88006bbc7f48
> >> ffffffff852adc60 0000000000000000 ffffffff852adc64 1ffffffff0b40135
> >> Call Trace:
> >> [<ffffffff8120c5ae>] lock_acquire+0x17e/0x340 kernel/locking/lockdep.c:3746
> >> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
> >> [<ffffffff83fb6fe1>] mutex_lock_nested+0xb1/0x890 kernel/locking/mutex.c:621
> >> [<ffffffff82db6fd0>] netlink_dump+0x50/0xac0 net/netlink/af_netlink.c:2067
> >> [<ffffffff82dba381>] __netlink_dump_start+0x501/0x770
> >> net/netlink/af_netlink.c:2200
> >> [<ffffffff82dc35b2>] genl_family_rcv_msg+0xa02/0xc80
> >> net/netlink/genetlink.c:595
> >> [<ffffffff82dc39e6>] genl_rcv_msg+0x1b6/0x270 net/netlink/genetlink.c:658
> >> [<ffffffff82dc1a70>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
> >> [<ffffffff82dc2b98>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:669
> >> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
> >> [<ffffffff82dc0329>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
> >> [<ffffffff82dc0fb7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
> >> [< inline >] sock_sendmsg_nosec net/socket.c:606
> >> [<ffffffff82b7075c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
> >> [<ffffffff82b709c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
> >> [< inline >] new_sync_write fs/read_write.c:499
> >> [<ffffffff8151c944>] __vfs_write+0x334/0x570 fs/read_write.c:512
> >> [<ffffffff8152045b>] vfs_write+0x17b/0x500 fs/read_write.c:560
> >> [< inline >] SYSC_write fs/read_write.c:607
> >> [<ffffffff81523d84>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> >> [<ffffffff83fc0141>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >> arch/x86/entry/entry_64.S:209
> >> Code: 0f 1f 44 00 00 f6 c4 02 0f 85 24 0a 00 00 44 8b 35 c9 61 8b 03
> >> 45 85 f6 74 2c 4c 89 fa 48 bb 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
> >> 3c 1a 00 0f 85 04 2f 00 00 49 81 3f a0 dc 2a 85 41 be 00 00
> >> RIP [<ffffffff8120872d>] __lock_acquire+0x12d/0x3450
> >> kernel/locking/lockdep.c:3221
> >> RSP <ffff88006bbc7420>
> >> ---[ end trace 685b3c182bf7f25c ]---
> >>
> >> The reproducer is attached.
> >>
> >> On commit 1a1891d762d6e64daf07b5be4817e3fbb29e3c59 (Oct 18).
> >
> > (Adding more maintainers)
> >
> > Still seeing this on 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
>
> Here is another report that might be related:
>
> =====================================
> [ BUG: bad unlock balance detected! ]
> 4.9.0-rc3+ #336 Not tainted
> -------------------------------------
> syz-executor/4018 is trying to release lock ([ 36.220068] nl_table_lock
> ) at:
> [<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
> but there are no more locks to release!
>
> other info that might help us debug this:
> 3 locks held by syz-executor/4018:
> #0: [ 36.220068] (
> sock_diag_mutex[ 36.220068] ){+.+.+.}
> , at: [ 36.220068] [<ffffffff82c3873b>] sock_diag_rcv+0x1b/0x40
> #1: [ 36.220068] (
> sock_diag_table_mutex[ 36.220068] ){+.+.+.}
> , at: [ 36.220068] [<ffffffff82c38e00>] sock_diag_rcv_msg+0x140/0x3a0
> #2: [ 36.220068] (
> nlk->cb_mutex[ 36.220068] ){+.+.+.}
> , at: [ 36.220068] [<ffffffff82db6600>] netlink_dump+0x50/0xac0
>
> stack backtrace:
> CPU: 1 PID: 4018 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff8800645df688 ffffffff81b46934 ffffffff84eb3e78 ffff88006ad85800
> ffffffff82dc8683 ffffffff84eb3e78 ffff8800645df6b8 ffffffff812043ca
> dffffc0000000000 ffff88006ad85ff8 ffff88006ad85fd0 00000000ffffffff
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
> [<ffffffff812043ca>] print_unlock_imbalance_bug+0x17a/0x1a0
> kernel/locking/lockdep.c:3388
> [< inline >] __lock_release kernel/locking/lockdep.c:3512
> [<ffffffff8120cfd8>] lock_release+0x8e8/0xc60 kernel/locking/lockdep.c:3765
> [< inline >] __raw_read_unlock ./include/linux/rwlock_api_smp.h:225
> [<ffffffff83fc001a>] _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
> [<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
> [<ffffffff82db6947>] netlink_dump+0x397/0xac0 net/netlink/af_netlink.c:2110
> [<ffffffff82db99b1>] __netlink_dump_start+0x501/0x770
> net/netlink/af_netlink.c:2200
> [< inline >] netlink_dump_start ./include/linux/netlink.h:165
> [<ffffffff82dc75d1>] netlink_diag_handler_dump+0x191/0x220
> net/netlink/diag.c:218
> [< inline >] __sock_diag_cmd net/core/sock_diag.c:239
> [<ffffffff82c38fd6>] sock_diag_rcv_msg+0x316/0x3a0 net/core/sock_diag.c:270
> [<ffffffff82dc10a0>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
> [<ffffffff82c3874a>] sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:281
> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
> [<ffffffff82dbf959>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
> [<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
> [< inline >] sock_sendmsg_nosec net/socket.c:606
> [<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
> [<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
> [< inline >] new_sync_write fs/read_write.c:499
> [<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
> [<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> [<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> arch/x86/entry/entry_64.S:209
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 4018 at net/core/skbuff.c:654[< none
> >] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
> Modules linked in:
> CPU: 1 PID: 4018 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff8800645df920 ffffffff81b46934 0000000000000000 0000000000000000
> ffffffff84401fa0 0000000000000000 ffff8800645df968 ffffffff811112f7
> ffffffff83fb92f2 ffff88000000028e ffffffff84401fa0 000000000000028e
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
> [<ffffffff811112f7>] __warn+0x1a7/0x1f0 kernel/panic.c:550
> [<ffffffff8111150c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
> [<ffffffff82b885ea>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
> [<ffffffff82b91815>] skb_release_all+0x15/0x60 net/core/skbuff.c:668
> [< inline >] __kfree_skb net/core/skbuff.c:684
> [<ffffffff82ba0175>] consume_skb+0x115/0x2e0 net/core/skbuff.c:757
> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1215
> [<ffffffff82dbf961>] netlink_unicast+0x5b1/0x880 net/netlink/af_netlink.c:1240
> [<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
> [< inline >] sock_sendmsg_nosec net/socket.c:606
> [<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
> [<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
> [< inline >] new_sync_write fs/read_write.c:499
> [<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
> [<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> [<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> arch/x86/entry/entry_64.S:209
> ---[ end trace bb9fa7cf182d59a5 ]---
> BUG: scheduling while atomic: syz-executor/4018/0x7fffffff
> INFO: lockdep is turned off.
> Modules linked in:
> CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff8800645dfe28 ffffffff81b46934 dffffc0000000000 000000007fffffff
> 00000000000214c0 0000000000000001 ffff8800645dfe48 ffffffff8119113a
> ffff88006cd214c0 0000000000000000 ffff8800645dfec8 ffffffff83fb030a
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
> [<ffffffff8119113a>] __schedule_bug+0xfa/0x140 kernel/sched/core.c:3230
> [< inline >] schedule_debug kernel/sched/core.c:3245
> [<ffffffff83fb030a>] __schedule+0xfda/0x1ab0 kernel/sched/core.c:3345
> [<ffffffff83fb0e70>] schedule+0x90/0x1b0 kernel/sched/core.c:3457
> [<ffffffff810039e9>] exit_to_usermode_loop+0xc9/0x130
> arch/x86/entry/common.c:149
> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
> [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
> arch/x86/entry/common.c:259
> [<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
> arch/x86/entry/entry_64.S:244
> NOHZ: local_softirq_pending 202
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 4018 at net/core/skbuff.c:654[< none
> >] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
> Modules linked in:[ 36.328353] CPU: 1 PID: 4018 Comm: syz-executor
> Tainted: G W 4.9.0-rc3+ #336
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff8800645df920 ffffffff81b46934 0000000000000000 0000000000000000
> ffffffff84401fa0 0000000000000000 ffff8800645df968 ffffffff811112f7
> ffffffff83fb92f2 ffff88000000028e ffffffff84401fa0 000000000000028e
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
> [<ffffffff811112f7>] __warn+0x1a7/0x1f0 kernel/panic.c:550
> [<ffffffff8111150c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
> [<ffffffff82b885ea>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
> [<ffffffff82b91815>] skb_release_all+0x15/0x60 net/core/skbuff.c:668
> [< inline >] __kfree_skb net/core/skbuff.c:684
> [<ffffffff82ba0175>] consume_skb+0x115/0x2e0 net/core/skbuff.c:757
> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1215
> [<ffffffff82dbf961>] netlink_unicast+0x5b1/0x880 net/netlink/af_netlink.c:1240
> [<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
> [< inline >] sock_sendmsg_nosec net/socket.c:606
> [<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
> [<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
> [< inline >] new_sync_write fs/read_write.c:499
> [<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
> [<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> [<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> arch/x86/entry/entry_64.S:209
> ---[ end trace bb9fa7cf182d59a6 ]---
> BUG: sleeping function called from invalid context at
> ./include/linux/freezer.h:56
> in_atomic(): 1, irqs_disabled(): 0, pid: 4018, name: syz-executor
> INFO: lockdep is turned off.
> CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff8800645dfbb0 ffffffff81b46934 ffff88006ad85800 ffff8800645d8000
> ffff88006ad85800 0000000000000000 ffff8800645dfbd8 ffffffff81192131
> ffff88006ad85800 ffffffff8404c140 0000000000000038 ffff8800645dfc18
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
> [<ffffffff81192131>] ___might_sleep+0x281/0x3c0 kernel/sched/core.c:7767
> [<ffffffff81192306>] __might_sleep+0x96/0x1a0 kernel/sched/core.c:7726
> [< inline >] try_to_freeze_unsafe ./include/linux/freezer.h:56
> [< inline >] try_to_freeze ./include/linux/freezer.h:66
> [<ffffffff81143849>] get_signal+0x129/0x15a0 kernel/signal.c:2147
> [<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
> [<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
> arch/x86/entry/common.c:156
> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
> [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
> arch/x86/entry/common.c:259
> [<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
> arch/x86/entry/entry_64.S:244
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff8800645df998 ffffffff81b46934 0000000000000003 dffffc0000000000
> dffffc0000000000 ffff8800645dfa04 ffff8800645dfa60 ffffffff8140bf7a
> 0000000041b58ab3 ffffffff84797a7d ffffffff8140bdbe ffffffff00000000
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
> [<ffffffff8140bf7a>] panic+0x1bc/0x39d kernel/panic.c:179
> [<ffffffff8111cfd8>] do_exit+0x1b48/0x2ac0 kernel/exit.c:740
> [<ffffffff811222be>] do_group_exit+0x10e/0x340 kernel/exit.c:931
> [<ffffffff81143d54>] get_signal+0x634/0x15a0 kernel/signal.c:2307
> [<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
> [<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
> arch/x86/entry/common.c:156
> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
> [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
> arch/x86/entry/common.c:259
> [<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
> arch/x86/entry/entry_64.S:244
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Aiee, killing interrupt handler!
This is probably a leftover after commit
ad202074320cd75b31b8cdb58cca0d4ef6aaea8a
("netlink: Use rhashtable walk interface in diag dump")
Please try this trivial fix :
diff --git a/net/netlink/diag.c b/net/netlink/diag.c
index b2f0e986a6f4..a5546249fb10 100644
--- a/net/netlink/diag.c
+++ b/net/netlink/diag.c
@@ -178,11 +178,8 @@ static int netlink_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
}
cb->args[1] = i;
} else {
- if (req->sdiag_protocol >= MAX_LINKS) {
- read_unlock(&nl_table_lock);
- rcu_read_unlock();
+ if (req->sdiag_protocol >= MAX_LINKS)
return -ENOENT;
- }
err = __netlink_diag_dump(skb, cb, req->sdiag_protocol, s_num);
}
^ permalink raw reply related
* Re: net/netlink: null-ptr-deref in netlink_dump/lock_acquire
From: Andrey Konovalov @ 2016-11-03 2:36 UTC (permalink / raw)
To: Andrew Morton, David Decotigny, David S. Miller, Dmitry Ivanov,
Eric Dumazet, Florian Westphal, Greg Rose, Herbert Xu,
Johannes Berg, Matti Vaittinen, Pravin B Shelar,
stephen hemminger, Tom Herbert, Tycho Andersen, LKML, netdev
Cc: syzkaller, Kostya Serebryany, Alexander Potapenko, Dmitry Vyukov
In-Reply-To: <CAAeHK+xCmN7n1MTocLK9A864YGkq-7a-1NESYkWyLYgLRScF=Q@mail.gmail.com>
On Thu, Nov 3, 2016 at 1:15 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Oct 19, 2016 at 4:13 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer:
>>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 3933 Comm: syz-executor Not tainted 4.9.0-rc1+ #230
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff88006b79d800 task.stack: ffff88006bbc0000
>> RIP: 0010:[<ffffffff8120872d>] [<ffffffff8120872d>]
>> __lock_acquire+0x12d/0x3450 kernel/locking/lockdep.c:3221
>> RSP: 0018:ffff88006bbc7420 EFLAGS: 00010006
>> RAX: 0000000000000046 RBX: dffffc0000000000 RCX: 0000000000000000
>> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000003
>> RBP: ffff88006bbc75c0 R08: 0000000000000001 R09: 0000000000000000
>> R10: 0000000000000000 R11: ffffffff85f42240 R12: ffff88006b79d800
>> R13: ffffffff84bfe4e0 R14: 0000000000000001 R15: 0000000000000060
>> FS: 00007fd9c41cc700(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000000451f80 CR3: 00000000638f0000 CR4: 00000000000006e0
>> Stack:
>> 0000000000000000 ffff88006bbc0000 ffff88006bbc8000 0000000000000000
>> 0000000000000002 ffff88006b79d800 0000000000000000 ffff88006bbc7f48
>> ffffffff852adc60 0000000000000000 ffffffff852adc64 1ffffffff0b40135
>> Call Trace:
>> [<ffffffff8120c5ae>] lock_acquire+0x17e/0x340 kernel/locking/lockdep.c:3746
>> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
>> [<ffffffff83fb6fe1>] mutex_lock_nested+0xb1/0x890 kernel/locking/mutex.c:621
>> [<ffffffff82db6fd0>] netlink_dump+0x50/0xac0 net/netlink/af_netlink.c:2067
>> [<ffffffff82dba381>] __netlink_dump_start+0x501/0x770
>> net/netlink/af_netlink.c:2200
>> [<ffffffff82dc35b2>] genl_family_rcv_msg+0xa02/0xc80
>> net/netlink/genetlink.c:595
>> [<ffffffff82dc39e6>] genl_rcv_msg+0x1b6/0x270 net/netlink/genetlink.c:658
>> [<ffffffff82dc1a70>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
>> [<ffffffff82dc2b98>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:669
>> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
>> [<ffffffff82dc0329>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
>> [<ffffffff82dc0fb7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
>> [< inline >] sock_sendmsg_nosec net/socket.c:606
>> [<ffffffff82b7075c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
>> [<ffffffff82b709c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
>> [< inline >] new_sync_write fs/read_write.c:499
>> [<ffffffff8151c944>] __vfs_write+0x334/0x570 fs/read_write.c:512
>> [<ffffffff8152045b>] vfs_write+0x17b/0x500 fs/read_write.c:560
>> [< inline >] SYSC_write fs/read_write.c:607
>> [<ffffffff81523d84>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
>> [<ffffffff83fc0141>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> Code: 0f 1f 44 00 00 f6 c4 02 0f 85 24 0a 00 00 44 8b 35 c9 61 8b 03
>> 45 85 f6 74 2c 4c 89 fa 48 bb 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
>> 3c 1a 00 0f 85 04 2f 00 00 49 81 3f a0 dc 2a 85 41 be 00 00
>> RIP [<ffffffff8120872d>] __lock_acquire+0x12d/0x3450
>> kernel/locking/lockdep.c:3221
>> RSP <ffff88006bbc7420>
>> ---[ end trace 685b3c182bf7f25c ]---
>>
>> The reproducer is attached.
>>
>> On commit 1a1891d762d6e64daf07b5be4817e3fbb29e3c59 (Oct 18).
>
> (Adding more maintainers)
>
> Still seeing this on 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
Here is another report that might be related:
=====================================
[ BUG: bad unlock balance detected! ]
4.9.0-rc3+ #336 Not tainted
-------------------------------------
syz-executor/4018 is trying to release lock ([ 36.220068] nl_table_lock
) at:
[<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
but there are no more locks to release!
other info that might help us debug this:
3 locks held by syz-executor/4018:
#0: [ 36.220068] (
sock_diag_mutex[ 36.220068] ){+.+.+.}
, at: [ 36.220068] [<ffffffff82c3873b>] sock_diag_rcv+0x1b/0x40
#1: [ 36.220068] (
sock_diag_table_mutex[ 36.220068] ){+.+.+.}
, at: [ 36.220068] [<ffffffff82c38e00>] sock_diag_rcv_msg+0x140/0x3a0
#2: [ 36.220068] (
nlk->cb_mutex[ 36.220068] ){+.+.+.}
, at: [ 36.220068] [<ffffffff82db6600>] netlink_dump+0x50/0xac0
stack backtrace:
CPU: 1 PID: 4018 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff8800645df688 ffffffff81b46934 ffffffff84eb3e78 ffff88006ad85800
ffffffff82dc8683 ffffffff84eb3e78 ffff8800645df6b8 ffffffff812043ca
dffffc0000000000 ffff88006ad85ff8 ffff88006ad85fd0 00000000ffffffff
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff812043ca>] print_unlock_imbalance_bug+0x17a/0x1a0
kernel/locking/lockdep.c:3388
[< inline >] __lock_release kernel/locking/lockdep.c:3512
[<ffffffff8120cfd8>] lock_release+0x8e8/0xc60 kernel/locking/lockdep.c:3765
[< inline >] __raw_read_unlock ./include/linux/rwlock_api_smp.h:225
[<ffffffff83fc001a>] _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
[<ffffffff82dc8683>] netlink_diag_dump+0x1a3/0x250 net/netlink/diag.c:182
[<ffffffff82db6947>] netlink_dump+0x397/0xac0 net/netlink/af_netlink.c:2110
[<ffffffff82db99b1>] __netlink_dump_start+0x501/0x770
net/netlink/af_netlink.c:2200
[< inline >] netlink_dump_start ./include/linux/netlink.h:165
[<ffffffff82dc75d1>] netlink_diag_handler_dump+0x191/0x220
net/netlink/diag.c:218
[< inline >] __sock_diag_cmd net/core/sock_diag.c:239
[<ffffffff82c38fd6>] sock_diag_rcv_msg+0x316/0x3a0 net/core/sock_diag.c:270
[<ffffffff82dc10a0>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
[<ffffffff82c3874a>] sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:281
[< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
[<ffffffff82dbf959>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
[<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
[< inline >] sock_sendmsg_nosec net/socket.c:606
[<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
[<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
------------[ cut here ]------------
WARNING: CPU: 1 PID: 4018 at net/core/skbuff.c:654[< none
>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
Modules linked in:
CPU: 1 PID: 4018 Comm: syz-executor Not tainted 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff8800645df920 ffffffff81b46934 0000000000000000 0000000000000000
ffffffff84401fa0 0000000000000000 ffff8800645df968 ffffffff811112f7
ffffffff83fb92f2 ffff88000000028e ffffffff84401fa0 000000000000028e
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff811112f7>] __warn+0x1a7/0x1f0 kernel/panic.c:550
[<ffffffff8111150c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
[<ffffffff82b885ea>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
[<ffffffff82b91815>] skb_release_all+0x15/0x60 net/core/skbuff.c:668
[< inline >] __kfree_skb net/core/skbuff.c:684
[<ffffffff82ba0175>] consume_skb+0x115/0x2e0 net/core/skbuff.c:757
[< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1215
[<ffffffff82dbf961>] netlink_unicast+0x5b1/0x880 net/netlink/af_netlink.c:1240
[<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
[< inline >] sock_sendmsg_nosec net/socket.c:606
[<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
[<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
---[ end trace bb9fa7cf182d59a5 ]---
BUG: scheduling while atomic: syz-executor/4018/0x7fffffff
INFO: lockdep is turned off.
Modules linked in:
CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff8800645dfe28 ffffffff81b46934 dffffc0000000000 000000007fffffff
00000000000214c0 0000000000000001 ffff8800645dfe48 ffffffff8119113a
ffff88006cd214c0 0000000000000000 ffff8800645dfec8 ffffffff83fb030a
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff8119113a>] __schedule_bug+0xfa/0x140 kernel/sched/core.c:3230
[< inline >] schedule_debug kernel/sched/core.c:3245
[<ffffffff83fb030a>] __schedule+0xfda/0x1ab0 kernel/sched/core.c:3345
[<ffffffff83fb0e70>] schedule+0x90/0x1b0 kernel/sched/core.c:3457
[<ffffffff810039e9>] exit_to_usermode_loop+0xc9/0x130
arch/x86/entry/common.c:149
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
arch/x86/entry/common.c:259
[<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
arch/x86/entry/entry_64.S:244
NOHZ: local_softirq_pending 202
------------[ cut here ]------------
WARNING: CPU: 1 PID: 4018 at net/core/skbuff.c:654[< none
>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
Modules linked in:[ 36.328353] CPU: 1 PID: 4018 Comm: syz-executor
Tainted: G W 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff8800645df920 ffffffff81b46934 0000000000000000 0000000000000000
ffffffff84401fa0 0000000000000000 ffff8800645df968 ffffffff811112f7
ffffffff83fb92f2 ffff88000000028e ffffffff84401fa0 000000000000028e
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff811112f7>] __warn+0x1a7/0x1f0 kernel/panic.c:550
[<ffffffff8111150c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
[<ffffffff82b885ea>] skb_release_head_state+0x1ca/0x240 net/core/skbuff.c:654
[<ffffffff82b91815>] skb_release_all+0x15/0x60 net/core/skbuff.c:668
[< inline >] __kfree_skb net/core/skbuff.c:684
[<ffffffff82ba0175>] consume_skb+0x115/0x2e0 net/core/skbuff.c:757
[< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1215
[<ffffffff82dbf961>] netlink_unicast+0x5b1/0x880 net/netlink/af_netlink.c:1240
[<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
[< inline >] sock_sendmsg_nosec net/socket.c:606
[<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
[<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
---[ end trace bb9fa7cf182d59a6 ]---
BUG: sleeping function called from invalid context at
./include/linux/freezer.h:56
in_atomic(): 1, irqs_disabled(): 0, pid: 4018, name: syz-executor
INFO: lockdep is turned off.
CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff8800645dfbb0 ffffffff81b46934 ffff88006ad85800 ffff8800645d8000
ffff88006ad85800 0000000000000000 ffff8800645dfbd8 ffffffff81192131
ffff88006ad85800 ffffffff8404c140 0000000000000038 ffff8800645dfc18
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff81192131>] ___might_sleep+0x281/0x3c0 kernel/sched/core.c:7767
[<ffffffff81192306>] __might_sleep+0x96/0x1a0 kernel/sched/core.c:7726
[< inline >] try_to_freeze_unsafe ./include/linux/freezer.h:56
[< inline >] try_to_freeze ./include/linux/freezer.h:66
[<ffffffff81143849>] get_signal+0x129/0x15a0 kernel/signal.c:2147
[<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
[<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
arch/x86/entry/common.c:156
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
arch/x86/entry/common.c:259
[<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
arch/x86/entry/entry_64.S:244
Kernel panic - not syncing: Aiee, killing interrupt handler!
CPU: 1 PID: 4018 Comm: syz-executor Tainted: G W 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff8800645df998 ffffffff81b46934 0000000000000003 dffffc0000000000
dffffc0000000000 ffff8800645dfa04 ffff8800645dfa60 ffffffff8140bf7a
0000000041b58ab3 ffffffff84797a7d ffffffff8140bdbe ffffffff00000000
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff8140bf7a>] panic+0x1bc/0x39d kernel/panic.c:179
[<ffffffff8111cfd8>] do_exit+0x1b48/0x2ac0 kernel/exit.c:740
[<ffffffff811222be>] do_group_exit+0x10e/0x340 kernel/exit.c:931
[<ffffffff81143d54>] get_signal+0x634/0x15a0 kernel/signal.c:2307
[<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
[<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
arch/x86/entry/common.c:156
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
arch/x86/entry/common.c:259
[<ffffffff83fc04a2>] entry_SYSCALL_64_fastpath+0xc0/0xc2
arch/x86/entry/entry_64.S:244
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Aiee, killing interrupt handler!
^ permalink raw reply
* Xmas Offer
From: Mrs Julie Leach @ 2016-11-03 1:37 UTC (permalink / raw)
To: Recipients
You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact ( julieleach93@gmail.com) for claims.
^ permalink raw reply
* [PATCH net] dccp: fix out of bound access in dccp_v4_err()
From: Eric Dumazet @ 2016-11-03 2:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Gerrit Renker, dccp
From: Eric Dumazet <edumazet@google.com>
dccp_v4_err() does not use pskb_may_pull() and might access garbage.
We only need 4 bytes at the beginning of the DCCP header, like TCP,
so the 8 bytes pulled in icmp_socket_deliver() are more than enough.
This patch might allow to process more ICMP messages, as some routers
are still limiting the size of reflected bytes to 28 (RFC 792), instead
of extended lengths (RFC 1812 4.3.2.3)
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/dccp/ipv4.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 345a3aeb8c7e..32f00ffdbf42 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -235,7 +235,7 @@ static void dccp_v4_err(struct sk_buff *skb, u32 info)
{
const struct iphdr *iph = (struct iphdr *)skb->data;
const u8 offset = iph->ihl << 2;
- const struct dccp_hdr *dh = (struct dccp_hdr *)(skb->data + offset);
+ const struct dccp_hdr *dh;
struct dccp_sock *dp;
struct inet_sock *inet;
const int type = icmp_hdr(skb)->type;
@@ -245,11 +245,13 @@ static void dccp_v4_err(struct sk_buff *skb, u32 info)
int err;
struct net *net = dev_net(skb->dev);
- if (skb->len < offset + sizeof(*dh) ||
- skb->len < offset + __dccp_basic_hdr_len(dh)) {
- __ICMP_INC_STATS(net, ICMP_MIB_INERRORS);
- return;
- }
+ /* Only need dccph_dport & dccph_sport which are the first
+ * 4 bytes in dccp header.
+ * Our caller (icmp_socket_deliver()) already pulled 8 bytes for us.
+ */
+ BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_sport) > 8);
+ BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_dport) > 8);
+ dh = (struct dccp_hdr *)(skb->data + offset);
sk = __inet_lookup_established(net, &dccp_hashinfo,
iph->daddr, dh->dccph_dport,
^ permalink raw reply related
* RE: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Shrijeet Mukherjee @ 2016-11-03 1:28 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Thomas Graf
Cc: Alexei Starovoitov, Jakub Kicinski, John Fastabend, David Miller,
alexander.duyck, mst, shrijeet, tom, netdev, Roopa Prabhu,
Nikolay Aleksandrov
In-Reply-To: <20161102152708.5cb40a0c@redhat.com>
> -----Original Message-----
> From: Jesper Dangaard Brouer [mailto:brouer@redhat.com]
> Sent: Wednesday, November 2, 2016 7:27 AM
> To: Thomas Graf <tgraf@suug.ch>
> Cc: Shrijeet Mukherjee <shm@cumulusnetworks.com>; Alexei Starovoitov
> <alexei.starovoitov@gmail.com>; Jakub Kicinski <kubakici@wp.pl>; John
> Fastabend <john.fastabend@gmail.com>; David Miller
> <davem@davemloft.net>; alexander.duyck@gmail.com; mst@redhat.com;
> shrijeet@gmail.com; tom@herbertland.com; netdev@vger.kernel.org;
> Roopa Prabhu <roopa@cumulusnetworks.com>; Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com>; brouer@redhat.com
> Subject: Re: [PATCH net-next RFC WIP] Patch for XDP support for
virtio_net
>
> On Sat, 29 Oct 2016 13:25:14 +0200
> Thomas Graf <tgraf@suug.ch> wrote:
>
> > On 10/28/16 at 08:51pm, Shrijeet Mukherjee wrote:
> > > Generally agree, but SRIOV nics with multiple queues can end up in a
> > > bad spot if each buffer was 4K right ? I see a specific page pool to
> > > be used by queues which are enabled for XDP as the easiest to swing
> > > solution that way the memory overhead can be restricted to enabled
> > > queues and shared access issues can be restricted to skb's using
that
> pool no ?
>
> Yes, that is why that I've been arguing so strongly for having the
flexibility to
> attach a XDP program per RX queue, as this only change the memory model
> for this one queue.
>
>
> > Isn't this clearly a must anyway? I may be missing something
> > fundamental here so please enlighten me :-)
> >
> > If we dedicate a page per packet, that could translate to 14M*4K worth
> > of memory being mapped per second for just a 10G NIC under DoS attack.
> > How can one protect such as system? Is the assumption that we can
> > always drop such packets quickly enough before we start dropping
> > randomly due to memory pressure? If a handshake is required to
> > determine validity of a packet then that is going to be difficult.
>
> Under DoS attacks you don't run out of memory, because a diverse set of
> socket memory limits/accounting avoids that situation. What does happen
> is the maximum achievable PPS rate is directly dependent on the
> time you spend on each packet. This use of CPU resources (and
> hitting mem-limits-safe-guards) push-back on the drivers speed to
process
> the RX ring. In effect, packets are dropped in the NIC HW as RX-ring
queue
> is not emptied fast-enough.
>
> Given you don't control what HW drops, the attacker will "successfully"
> cause your good traffic to be among the dropped packets.
>
> This is where XDP change the picture. If you can express (by eBPF) a
filter
> that can separate "bad" vs "good" traffic, then you can take back
control.
> Almost like controlling what traffic the HW should drop.
> Given the cost of XDP-eBPF filter + serving regular traffic does not use
all of
> your CPU resources, you have overcome the attack.
>
> --
Jesper, John et al .. to make this a little concrete I am going to spin
up a v2 which has only bigbuffers mode enabled for xdp acceleration, all
other modes will reject the xdp ndo ..
Do we have agreement on that model ?
It will need that all vhost implementations will need to start with
mergeable buffers disabled to get xdp goodness, but that sounds like a
safe thing to do for now ..
^ permalink raw reply
* Re: [PATCH net 1/1] driver: veth: Return the actual value instead return NETDEV_TX_OK always
From: Gao Feng @ 2016-11-03 1:04 UTC (permalink / raw)
To: Florian Fainelli
Cc: Cong Wang, David Miller, Cong Wang, Vijay Pandurangan, Evan Jones,
pabeni, Linux Kernel Network Developers
In-Reply-To: <704bff33-d376-1825-07d1-b2e11775e9d4@gmail.com>
Hi Florian,
On Thu, Nov 3, 2016 at 8:58 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 11/02/2016 05:52 PM, Gao Feng wrote:
>> Hi Cong,
>>
>> On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> On Wed, Nov 2, 2016 at 2:59 AM, <fgao@ikuai8.com> wrote:
>>>> From: Gao Feng <fgao@ikuai8.com>
>>>>
>>>> Current veth_xmit always returns NETDEV_TX_OK whatever if it is really
>>>> sent successfully. Now return the actual value instead of NETDEV_TX_OK
>>>> always.
>>>>
>>>> Signed-off-by: Gao Feng <fgao@ikuai8.com>
>>>> ---
>>>> drivers/net/veth.c | 7 +++++--
>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>>>> index fbc853e..769a3bd 100644
>>>> --- a/drivers/net/veth.c
>>>> +++ b/drivers/net/veth.c
>>>> @@ -111,15 +111,18 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
>>>> struct veth_priv *priv = netdev_priv(dev);
>>>> struct net_device *rcv;
>>>> int length = skb->len;
>>>> + int ret = NETDEV_TX_OK;
>>>>
>>>> rcu_read_lock();
>>>> rcv = rcu_dereference(priv->peer);
>>>> if (unlikely(!rcv)) {
>>>> kfree_skb(skb);
>>>> + ret = NET_RX_DROP;
>>>
>>>
>>> Returning NET_RX_DROP doesn't look correct in a xmit function.
>>
>> Yes. But I don't find good macro.
>> NETDEV_TX_BUSY or NET_RX_DROP, which is better ?
>
> There is no much choice you need to return a correct value from the
> netdev_tx_t enum, which NET_RX_DROP is not part of, so that probably
> means using NETDEV_TX_OK here, the packet has been freed, and there is
> no flow control problem mandating the return of NETDEV_TX_BUSY it seems...
> --
> Florian
Thanks your explanation.
It means the veth_xmit must return NETDEV_TX_OK.
Regards
Feng
^ permalink raw reply
* [PATCH net] dccp: do not send reset to already closed sockets
From: Eric Dumazet @ 2016-11-03 1:04 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Gerrit Renker, David S. Miller, dccp, netdev, syzkaller,
Kostya Serebryany, Alexander Potapenko, Eric Dumazet,
Dmitry Vyukov
In-Reply-To: <CAAeHK+zBgPzp9KBCJb7_Q2Nm3n+t5HeuFwEFCDDc7cw234nREA@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Andrey reported following warning while fuzzing with syzkaller
WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83 dccp_set_state+0x229/0x290
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 21072 Comm: syz-executor Not tainted 4.9.0-rc1+ #293
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88003d4c7738 ffffffff81b474f4 0000000000000003 dffffc0000000000
ffffffff844f8b00 ffff88003d4c7804 ffff88003d4c7800 ffffffff8140c06a
0000000041b58ab3 ffffffff8479ab7d ffffffff8140beae ffffffff8140cd00
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b474f4>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[<ffffffff8140c06a>] panic+0x1bc/0x39d kernel/panic.c:179
[<ffffffff8111125c>] __warn+0x1cc/0x1f0 kernel/panic.c:542
[<ffffffff8111144c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
[<ffffffff8389e5d9>] dccp_set_state+0x229/0x290 net/dccp/proto.c:83
[<ffffffff838a0aa2>] dccp_close+0x612/0xc10 net/dccp/proto.c:1016
[<ffffffff8316bf1f>] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415
[<ffffffff82b6e89e>] sock_release+0x8e/0x1d0 net/socket.c:570
[<ffffffff82b6e9f6>] sock_close+0x16/0x20 net/socket.c:1017
[<ffffffff815256ad>] __fput+0x29d/0x720 fs/file_table.c:208
[<ffffffff81525bb5>] ____fput+0x15/0x20 fs/file_table.c:244
[<ffffffff811727d8>] task_work_run+0xf8/0x170 kernel/task_work.c:116
[< inline >] exit_task_work include/linux/task_work.h:21
[<ffffffff8111bc53>] do_exit+0x883/0x2ac0 kernel/exit.c:828
[<ffffffff811221fe>] do_group_exit+0x10e/0x340 kernel/exit.c:931
[<ffffffff81143c94>] get_signal+0x634/0x15a0 kernel/signal.c:2307
[<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
[<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
arch/x86/entry/common.c:156
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
[<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
arch/x86/entry/common.c:259
[<ffffffff83fc1a62>] entry_SYSCALL_64_fastpath+0xc0/0xc2
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Fix this the same way we did for TCP in commit 565b7b2d2e63
("tcp: do not send reset to already closed sockets")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
---
net/dccp/proto.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index 41e65804ddf5..9fe25bf63296 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -1009,6 +1009,10 @@ void dccp_close(struct sock *sk, long timeout)
__kfree_skb(skb);
}
+ /* If socket has been already reset kill it. */
+ if (sk->sk_state == DCCP_CLOSED)
+ goto adjudge_to_death;
+
if (data_was_unread) {
/* Unread data was tossed, send an appropriate Reset Code */
DCCP_WARN("ABORT with %u bytes unread\n", data_was_unread);
^ permalink raw reply related
* Re: [PATCH 1/2] rtl8xxxu: Fix for authentication failure
From: Larry Finger @ 2016-11-03 1:00 UTC (permalink / raw)
To: John Heenan, Jes Sorensen, Kalle Valo, linux-wireless, netdev
Cc: linux-kernel
In-Reply-To: <20161030102046.GA5784@cube>
On 10/30/2016 05:20 AM, John Heenan wrote:
> This fix enables the same sequence of init behaviour as the alternative
> working driver for the wireless rtl8723bu IC at
> https://github.com/lwfinger/rtl8723bu
>
> For exampe rtl8xxxu_init_device is now called each time
> userspace wpa_supplicant is executed instead of just once when
> modprobe is executed.
After all the trouble you have had with your patches, I would expect you to use
more care when composing the commit message. Note the typo in the paragraph above.
> Along with 'Fix for bogus data used to determine macpower',
> wpa_supplicant now reliably and successfully authenticates.
I'm not sure this paragraph belongs in the permanent commit record.
> For rtl8xxxu-devel branch of git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
I know this line does not belong. If you want to include information like this,
include it after a line containing "---". Those lines will be available to
reviewers and maintainers, but will be stripped before it gets included in the
code base.
> Signed-off-by: John Heenan <john@zgus.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 04141e5..f25b4df 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -5779,6 +5779,11 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>
> ret = 0;
>
> + ret = rtl8xxxu_init_device(hw);
> + if (ret)
> + goto error_out;
> +
> +
> init_usb_anchor(&priv->rx_anchor);
> init_usb_anchor(&priv->tx_anchor);
> init_usb_anchor(&priv->int_anchor);
> @@ -6080,10 +6085,6 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> goto exit;
> }
>
> - ret = rtl8xxxu_init_device(hw);
> - if (ret)
> - goto exit;
> -
> hw->wiphy->max_scan_ssids = 1;
> hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
> hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
>
I will let Jes comment on any side effects of this code change.
Larry
--
If I was stranded on an island and the only way to get off
the island was to make a pretty UI, I’d die there.
Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: Larry Finger @ 2016-11-03 1:00 UTC (permalink / raw)
To: John Heenan, Jes Sorensen, Kalle Valo, linux-wireless, netdev
Cc: linux-kernel
In-Reply-To: <20161030102112.GA5789@cube>
On 10/30/2016 05:21 AM, John Heenan wrote:
> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set
> macpower, is never 0xea. It is only ever 0x01 (first time after modprobe)
> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results
> occurs with 'Fix for authentication failure' [PATCH 1/2] in place.
>
> Whatever was returned, code tests always showed that at least
> rtl8xxxu_init_queue_reserved_page(priv);
> is always required. Not called if macpower set to true.
>
> Please see cover letter, [PATCH 0/2], for more information from tests.
That cover letter will NOT be included in the commit message, thus referring to
it here is totally pointless.
>
> For rtl8xxxu-devel branch of git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
Same comment as for the previous patch.
Again I leave the review of the code changes to Jes.
Larry
^ permalink raw reply
* Re: [PATCH net 1/1] driver: veth: Return the actual value instead return NETDEV_TX_OK always
From: Florian Fainelli @ 2016-11-03 0:58 UTC (permalink / raw)
To: Gao Feng, Cong Wang
Cc: David Miller, Cong Wang, Vijay Pandurangan, Evan Jones, pabeni,
Linux Kernel Network Developers
In-Reply-To: <CA+6hz4rWLM_LkABr_cegdx66V2BBsR2Z7NuTMaDuBH2KZdOTSA@mail.gmail.com>
On 11/02/2016 05:52 PM, Gao Feng wrote:
> Hi Cong,
>
> On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Wed, Nov 2, 2016 at 2:59 AM, <fgao@ikuai8.com> wrote:
>>> From: Gao Feng <fgao@ikuai8.com>
>>>
>>> Current veth_xmit always returns NETDEV_TX_OK whatever if it is really
>>> sent successfully. Now return the actual value instead of NETDEV_TX_OK
>>> always.
>>>
>>> Signed-off-by: Gao Feng <fgao@ikuai8.com>
>>> ---
>>> drivers/net/veth.c | 7 +++++--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>>> index fbc853e..769a3bd 100644
>>> --- a/drivers/net/veth.c
>>> +++ b/drivers/net/veth.c
>>> @@ -111,15 +111,18 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
>>> struct veth_priv *priv = netdev_priv(dev);
>>> struct net_device *rcv;
>>> int length = skb->len;
>>> + int ret = NETDEV_TX_OK;
>>>
>>> rcu_read_lock();
>>> rcv = rcu_dereference(priv->peer);
>>> if (unlikely(!rcv)) {
>>> kfree_skb(skb);
>>> + ret = NET_RX_DROP;
>>
>>
>> Returning NET_RX_DROP doesn't look correct in a xmit function.
>
> Yes. But I don't find good macro.
> NETDEV_TX_BUSY or NET_RX_DROP, which is better ?
There is no much choice you need to return a correct value from the
netdev_tx_t enum, which NET_RX_DROP is not part of, so that probably
means using NETDEV_TX_OK here, the packet has been freed, and there is
no flow control problem mandating the return of NETDEV_TX_BUSY it seems...
--
Florian
^ permalink raw reply
* Re: [PATCH net 1/1] driver: veth: Return the actual value instead return NETDEV_TX_OK always
From: Gao Feng @ 2016-11-03 0:52 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Cong Wang, Vijay Pandurangan, Evan Jones, pabeni,
Linux Kernel Network Developers
In-Reply-To: <CAM_iQpW4HmtoSAiKSyq9o0MXpL1R8XL2-r3NsPH6xu9Pd4X8XA@mail.gmail.com>
Hi Cong,
On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Nov 2, 2016 at 2:59 AM, <fgao@ikuai8.com> wrote:
>> From: Gao Feng <fgao@ikuai8.com>
>>
>> Current veth_xmit always returns NETDEV_TX_OK whatever if it is really
>> sent successfully. Now return the actual value instead of NETDEV_TX_OK
>> always.
>>
>> Signed-off-by: Gao Feng <fgao@ikuai8.com>
>> ---
>> drivers/net/veth.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>> index fbc853e..769a3bd 100644
>> --- a/drivers/net/veth.c
>> +++ b/drivers/net/veth.c
>> @@ -111,15 +111,18 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
>> struct veth_priv *priv = netdev_priv(dev);
>> struct net_device *rcv;
>> int length = skb->len;
>> + int ret = NETDEV_TX_OK;
>>
>> rcu_read_lock();
>> rcv = rcu_dereference(priv->peer);
>> if (unlikely(!rcv)) {
>> kfree_skb(skb);
>> + ret = NET_RX_DROP;
>
>
> Returning NET_RX_DROP doesn't look correct in a xmit function.
Yes. But I don't find good macro.
NETDEV_TX_BUSY or NET_RX_DROP, which is better ?
Thanks
Feng
>
>
>> goto drop;
>> }
>>
>> - if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {
>> + ret = dev_forward_skb(rcv, skb);
>> + if (likely(ret == NET_RX_SUCCESS)) {
>> struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);
>>
>> u64_stats_update_begin(&stats->syncp);
>> @@ -131,7 +134,7 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
>> atomic64_inc(&priv->dropped);
>> }
>> rcu_read_unlock();
>> - return NETDEV_TX_OK;
>> + return ret;
>> }
>>
>> /*
>> --
>> 1.9.1
>>
>>
^ permalink raw reply
* Fwd: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla
From: Andrey Konovalov @ 2016-11-03 0:26 UTC (permalink / raw)
To: David S. Miller, Nicolas Dichtel, LKML, Matti Vaittinen,
Tycho Andersen, stephen hemminger, Tom Herbert, Florian Westphal,
netdev
Cc: Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller
In-Reply-To: <CAAeHK+xm5_n-Ep2d4YEq=Yx=f5M2NpV-So0o7811LUk+pLr+rg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
Hi,
I've got the following error report while running the syzkaller fuzzer:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla+0x49b/0x4e0 at addr
ffffffff8407e3ac
Read of size 2 by task a.out/3877
Address belongs to variable[< none >]
cgroupstats_cmd_get_policy+0xc/0x40 ??:?
CPU: 1 PID: 3877 Comm: a.out Not tainted 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff880063077690 ffffffff81b46934 ffff880063077720 ffffffff847a369f
ffffffff8407e3a0 ffffffff8407e3ac ffff880063077710 ffffffff8150ac7c
ffffffff85f44280 ffff88006aec1de8 ffff88006aec1e38 0000000000000286
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[< inline >] print_address_description mm/kasan/report.c:204
[<ffffffff8150ac7c>] kasan_report_error+0x49c/0x4d0 mm/kasan/report.c:283
[< inline >] kasan_report mm/kasan/report.c:303
[<ffffffff8150ad2e>] __asan_report_load2_noabort+0x3e/0x40
mm/kasan/report.c:322
[<ffffffff81be27eb>] validate_nla+0x49b/0x4e0 lib/nlattr.c:41
[<ffffffff81be2ab5>] nla_parse+0x115/0x280 lib/nlattr.c:195
[< inline >] nlmsg_parse ./include/net/netlink.h:386
[<ffffffff82dc2723>] genl_family_rcv_msg+0x543/0xc80
net/netlink/genetlink.c:613
[<ffffffff82dc3016>] genl_rcv_msg+0x1b6/0x270 net/netlink/genetlink.c:658
[<ffffffff82dc10a0>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
[<ffffffff82dc21c8>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:669
[< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
[<ffffffff82dbf959>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
[<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
[< inline >] sock_sendmsg_nosec net/socket.c:606
[<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
[<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
Memory state around the buggy address:
ffffffff8407e280: 00 02 fa fa fa fa fa fa 00 00 00 00 02 fa fa fa
ffffffff8407e300: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff8407e380: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 04 fa
^
ffffffff8407e400: fa fa fa fa 00 00 00 00 00 02 fa fa fa fa fa fa
ffffffff8407e480: 00 00 00 03 fa fa fa fa 00 00 00 00 00 01 fa fa
==================================================================
A reproducer is attached.
On commit 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
Thanks!
[-- Attachment #2: netlink-validate-oob-poc.c --]
[-- Type: application/octet-stream, Size: 6353 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_syz_inject_blob
#define __NR_syz_inject_blob 1000006
#endif
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 1000003
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_write
#define __NR_write 1
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 1000004
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 1000005
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 1000002
#endif
#ifndef __NR_syz_test
#define __NR_syz_test 1000001
#endif
#include <fcntl.h>
#include <pthread.h>
#include <setjmp.h>
#include <signal.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, "", target, "fuse", flags, buf);
return fd;
}
static uintptr_t syz_fuseblk_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7)
{
uint64_t target = a0;
uint64_t blkdev = a1;
uint64_t mode = a2;
uint64_t uid = a3;
uint64_t gid = a4;
uint64_t maxread = a5;
uint64_t blksize = a6;
uint64_t flags = a7;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
if (syscall(SYS_mknodat, AT_FDCWD, blkdev, S_IFBLK, makedev(7, 199)))
return fd;
char buf[256];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (blksize != 0)
sprintf(buf + strlen(buf), ",blksize=%ld", (long)blksize);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, blkdev, target, "fuseblk", flags, buf);
return fd;
}
static uintptr_t syz_inject_blob(uintptr_t a0)
{
int fd = open("/sys/kernel/debug/syz_vnet", O_RDWR);
if (fd == -1)
return fd;
ioctl(fd, 0, (void*)a0);
close(fd);
return 0;
}
static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7,
uintptr_t a8)
{
switch (nr) {
default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
case __NR_syz_test:
return 0;
case __NR_syz_open_dev:
return syz_open_dev(a0, a1, a2);
case __NR_syz_open_pts:
return syz_open_pts(a0, a1);
case __NR_syz_fuse_mount:
return syz_fuse_mount(a0, a1, a2, a3, a4, a5);
case __NR_syz_fuseblk_mount:
return syz_fuseblk_mount(a0, a1, a2, a3, a4, a5, a6, a7);
case __NR_syz_inject_blob:
return syz_inject_blob(a0);
}
}
long r[5];
int main()
{
install_segv_handler();
memset(r, -1, sizeof(r));
r[0] = execute_syscall(__NR_mmap, 0x20f26000ul, 0x4000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
r[1] = execute_syscall(__NR_socket, 0x10ul, 0x3ul, 0x10ul, 0, 0, 0, 0,
0, 0);
r[2] = execute_syscall(__NR_mmap, 0x20f1b000ul, 0x1000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
NONFAILING(memcpy((void*)0x20f1bfd6,
"\x1f\x00\x00\x00\x2f\x00\x07\x06\x00\x00\x00\x05"
"\x29\xff\x0f\xff\x04\x00\x00\x00\x05\x00\x03\x00"
"\x03\x4b\x00\xa0\x01\x08\xa0\xeb\xfb\x7f\xff\xff"
"\xff\xf9\xa9\x47\xe6\xe4",
42));
r[4] = execute_syscall(__NR_write, r[1], 0x20f1bfd6ul, 0x2aul, 0, 0,
0, 0, 0, 0);
return 0;
}
^ permalink raw reply
* net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla
From: Andrey Konovalov @ 2016-11-03 0:25 UTC (permalink / raw)
To: David S. Miller, Nicolas Dichtel, LKML, Matti Vaittinen,
Tycho Andersen, stephen hemminger, Tom Herbert, Florian Westphal,
netdev
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
Hi,
I've got the following error report while running the syzkaller fuzzer:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla+0x49b/0x4e0 at addr
ffffffff8407e3ac
Read of size 2 by task a.out/3877
Address belongs to variable[< none >]
cgroupstats_cmd_get_policy+0xc/0x40 ??:?
CPU: 1 PID: 3877 Comm: a.out Not tainted 4.9.0-rc3+ #336
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff880063077690 ffffffff81b46934 ffff880063077720 ffffffff847a369f
ffffffff8407e3a0 ffffffff8407e3ac ffff880063077710 ffffffff8150ac7c
ffffffff85f44280 ffff88006aec1de8 ffff88006aec1e38 0000000000000286
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b46934>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[< inline >] print_address_description mm/kasan/report.c:204
[<ffffffff8150ac7c>] kasan_report_error+0x49c/0x4d0 mm/kasan/report.c:283
[< inline >] kasan_report mm/kasan/report.c:303
[<ffffffff8150ad2e>] __asan_report_load2_noabort+0x3e/0x40
mm/kasan/report.c:322
[<ffffffff81be27eb>] validate_nla+0x49b/0x4e0 lib/nlattr.c:41
[<ffffffff81be2ab5>] nla_parse+0x115/0x280 lib/nlattr.c:195
[< inline >] nlmsg_parse ./include/net/netlink.h:386
[<ffffffff82dc2723>] genl_family_rcv_msg+0x543/0xc80
net/netlink/genetlink.c:613
[<ffffffff82dc3016>] genl_rcv_msg+0x1b6/0x270 net/netlink/genetlink.c:658
[<ffffffff82dc10a0>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
[<ffffffff82dc21c8>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:669
[< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
[<ffffffff82dbf959>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
[<ffffffff82dc05e7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
[< inline >] sock_sendmsg_nosec net/socket.c:606
[<ffffffff82b6f75c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
[<ffffffff82b6f9c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151bd44>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151f85b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523184>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc0401>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
Memory state around the buggy address:
ffffffff8407e280: 00 02 fa fa fa fa fa fa 00 00 00 00 02 fa fa fa
ffffffff8407e300: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff8407e380: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 04 fa
^
ffffffff8407e400: fa fa fa fa 00 00 00 00 00 02 fa fa fa fa fa fa
ffffffff8407e480: 00 00 00 03 fa fa fa fa 00 00 00 00 00 01 fa fa
==================================================================
A reproducer is attached.
On commit 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
Thanks!
[-- Attachment #2: netlink-validate-oob-poc.c --]
[-- Type: application/octet-stream, Size: 6353 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_syz_inject_blob
#define __NR_syz_inject_blob 1000006
#endif
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 1000003
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_write
#define __NR_write 1
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 1000004
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 1000005
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 1000002
#endif
#ifndef __NR_syz_test
#define __NR_syz_test 1000001
#endif
#include <fcntl.h>
#include <pthread.h>
#include <setjmp.h>
#include <signal.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, "", target, "fuse", flags, buf);
return fd;
}
static uintptr_t syz_fuseblk_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7)
{
uint64_t target = a0;
uint64_t blkdev = a1;
uint64_t mode = a2;
uint64_t uid = a3;
uint64_t gid = a4;
uint64_t maxread = a5;
uint64_t blksize = a6;
uint64_t flags = a7;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
if (syscall(SYS_mknodat, AT_FDCWD, blkdev, S_IFBLK, makedev(7, 199)))
return fd;
char buf[256];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (blksize != 0)
sprintf(buf + strlen(buf), ",blksize=%ld", (long)blksize);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, blkdev, target, "fuseblk", flags, buf);
return fd;
}
static uintptr_t syz_inject_blob(uintptr_t a0)
{
int fd = open("/sys/kernel/debug/syz_vnet", O_RDWR);
if (fd == -1)
return fd;
ioctl(fd, 0, (void*)a0);
close(fd);
return 0;
}
static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7,
uintptr_t a8)
{
switch (nr) {
default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
case __NR_syz_test:
return 0;
case __NR_syz_open_dev:
return syz_open_dev(a0, a1, a2);
case __NR_syz_open_pts:
return syz_open_pts(a0, a1);
case __NR_syz_fuse_mount:
return syz_fuse_mount(a0, a1, a2, a3, a4, a5);
case __NR_syz_fuseblk_mount:
return syz_fuseblk_mount(a0, a1, a2, a3, a4, a5, a6, a7);
case __NR_syz_inject_blob:
return syz_inject_blob(a0);
}
}
long r[5];
int main()
{
install_segv_handler();
memset(r, -1, sizeof(r));
r[0] = execute_syscall(__NR_mmap, 0x20f26000ul, 0x4000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
r[1] = execute_syscall(__NR_socket, 0x10ul, 0x3ul, 0x10ul, 0, 0, 0, 0,
0, 0);
r[2] = execute_syscall(__NR_mmap, 0x20f1b000ul, 0x1000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
NONFAILING(memcpy((void*)0x20f1bfd6,
"\x1f\x00\x00\x00\x2f\x00\x07\x06\x00\x00\x00\x05"
"\x29\xff\x0f\xff\x04\x00\x00\x00\x05\x00\x03\x00"
"\x03\x4b\x00\xa0\x01\x08\xa0\xeb\xfb\x7f\xff\xff"
"\xff\xf9\xa9\x47\xe6\xe4",
42));
r[4] = execute_syscall(__NR_write, r[1], 0x20f1bfd6ul, 0x2aul, 0, 0,
0, 0, 0, 0);
return 0;
}
^ permalink raw reply
* Re: net/netlink: null-ptr-deref in netlink_dump/lock_acquire
From: Andrey Konovalov @ 2016-11-03 0:15 UTC (permalink / raw)
To: Andrew Morton, David Decotigny, David S. Miller, Dmitry Ivanov,
Eric Dumazet, Florian Westphal, Greg Rose, Herbert Xu,
Johannes Berg, Matti Vaittinen, Pravin B Shelar,
stephen hemminger, Tom Herbert, Tycho Andersen, LKML, netdev
Cc: syzkaller, Kostya Serebryany, Alexander Potapenko, Dmitry Vyukov
In-Reply-To: <CAAeHK+wM9yG3c9AksSyj7jYSY4ujssH+vTuV2nyz=-0enLrB8w@mail.gmail.com>
On Wed, Oct 19, 2016 at 4:13 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Modules linked in:
> CPU: 1 PID: 3933 Comm: syz-executor Not tainted 4.9.0-rc1+ #230
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff88006b79d800 task.stack: ffff88006bbc0000
> RIP: 0010:[<ffffffff8120872d>] [<ffffffff8120872d>]
> __lock_acquire+0x12d/0x3450 kernel/locking/lockdep.c:3221
> RSP: 0018:ffff88006bbc7420 EFLAGS: 00010006
> RAX: 0000000000000046 RBX: dffffc0000000000 RCX: 0000000000000000
> RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000003
> RBP: ffff88006bbc75c0 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: ffffffff85f42240 R12: ffff88006b79d800
> R13: ffffffff84bfe4e0 R14: 0000000000000001 R15: 0000000000000060
> FS: 00007fd9c41cc700(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000451f80 CR3: 00000000638f0000 CR4: 00000000000006e0
> Stack:
> 0000000000000000 ffff88006bbc0000 ffff88006bbc8000 0000000000000000
> 0000000000000002 ffff88006b79d800 0000000000000000 ffff88006bbc7f48
> ffffffff852adc60 0000000000000000 ffffffff852adc64 1ffffffff0b40135
> Call Trace:
> [<ffffffff8120c5ae>] lock_acquire+0x17e/0x340 kernel/locking/lockdep.c:3746
> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
> [<ffffffff83fb6fe1>] mutex_lock_nested+0xb1/0x890 kernel/locking/mutex.c:621
> [<ffffffff82db6fd0>] netlink_dump+0x50/0xac0 net/netlink/af_netlink.c:2067
> [<ffffffff82dba381>] __netlink_dump_start+0x501/0x770
> net/netlink/af_netlink.c:2200
> [<ffffffff82dc35b2>] genl_family_rcv_msg+0xa02/0xc80
> net/netlink/genetlink.c:595
> [<ffffffff82dc39e6>] genl_rcv_msg+0x1b6/0x270 net/netlink/genetlink.c:658
> [<ffffffff82dc1a70>] netlink_rcv_skb+0x2c0/0x3b0 net/netlink/af_netlink.c:2281
> [<ffffffff82dc2b98>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:669
> [< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
> [<ffffffff82dc0329>] netlink_unicast+0x5a9/0x880 net/netlink/af_netlink.c:1240
> [<ffffffff82dc0fb7>] netlink_sendmsg+0x9b7/0xce0 net/netlink/af_netlink.c:1786
> [< inline >] sock_sendmsg_nosec net/socket.c:606
> [<ffffffff82b7075c>] sock_sendmsg+0xcc/0x110 net/socket.c:616
> [<ffffffff82b709c1>] sock_write_iter+0x221/0x3b0 net/socket.c:814
> [< inline >] new_sync_write fs/read_write.c:499
> [<ffffffff8151c944>] __vfs_write+0x334/0x570 fs/read_write.c:512
> [<ffffffff8152045b>] vfs_write+0x17b/0x500 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<ffffffff81523d84>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> [<ffffffff83fc0141>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> arch/x86/entry/entry_64.S:209
> Code: 0f 1f 44 00 00 f6 c4 02 0f 85 24 0a 00 00 44 8b 35 c9 61 8b 03
> 45 85 f6 74 2c 4c 89 fa 48 bb 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
> 3c 1a 00 0f 85 04 2f 00 00 49 81 3f a0 dc 2a 85 41 be 00 00
> RIP [<ffffffff8120872d>] __lock_acquire+0x12d/0x3450
> kernel/locking/lockdep.c:3221
> RSP <ffff88006bbc7420>
> ---[ end trace 685b3c182bf7f25c ]---
>
> The reproducer is attached.
>
> On commit 1a1891d762d6e64daf07b5be4817e3fbb29e3c59 (Oct 18).
(Adding more maintainers)
Still seeing this on 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31).
^ 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