* Re: [PATCH bpf-next 0/2] nfp: bpf: add programmable RSS support
From: Alexei Starovoitov @ 2018-05-09 2:42 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: daniel, davem, netdev, oss-drivers
In-Reply-To: <20180509023707.23601-1-jakub.kicinski@netronome.com>
On Tue, May 08, 2018 at 07:37:05PM -0700, Jakub Kicinski wrote:
> Hi!
>
> This small series adds a feature which extends BPF offload beyond
> a pure host processing offload and firmly into the realm of
> heterogeneous processing. Allowing offloaded XDP programs to set
> the RX queue index opens the door for defining fully programmable
> RSS/n-tuple filter replacement. In fact the device datapath will
> skip the RSS processing completely if BPF decided on the queue
> already, making the XDP program replace part of the standard NIC
> datapath.
Absolutely love it!
Huge feature enabled by such tiny diff.
For the set:
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [PATCH bpf] nfp: bpf: allow zero-length capabilities
From: Jakub Kicinski @ 2018-05-09 2:42 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: oss-drivers, netdev, Jakub Kicinski
Some BPF capabilities carry no value, they simply indicate feature
is present. Our capability parsing loop will exit early if last
capability is zero-length because it's looking for more than 8 bytes
of data (8B is our TLV header length). Allow the last capability to
be zero-length.
This bug would lead to driver failing to probe with the following error
if the last capability FW advertises is zero-length:
nfp: BPF capabilities left after parsing, parsed:92 total length:100
nfp: invalid BPF capabilities at offset:92
Note the "parsed" and "length" values are 8 apart.
No shipping FW runs into this issue, but we can't guarantee that will
remain the case.
Fixes: 77a844ee650c ("nfp: bpf: prepare for parsing BPF FW capabilities")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
drivers/net/ethernet/netronome/nfp/bpf/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/bpf/main.c b/drivers/net/ethernet/netronome/nfp/bpf/main.c
index 1dc424685f4e..35fb31f682af 100644
--- a/drivers/net/ethernet/netronome/nfp/bpf/main.c
+++ b/drivers/net/ethernet/netronome/nfp/bpf/main.c
@@ -335,7 +335,7 @@ static int nfp_bpf_parse_capabilities(struct nfp_app *app)
return PTR_ERR(mem) == -ENOENT ? 0 : PTR_ERR(mem);
start = mem;
- while (mem - start + 8 < nfp_cpp_area_size(area)) {
+ while (mem - start + 8 <= nfp_cpp_area_size(area)) {
u8 __iomem *value;
u32 type, length;
--
2.17.0
^ permalink raw reply related
* Re: ICMP redirect and VRF
From: David Ahern @ 2018-05-09 2:47 UTC (permalink / raw)
To: Ben Greear, netdev
In-Reply-To: <eef63cf1-64db-d9ed-7aaf-b6b4e60bb07c@candelatech.com>
On 5/8/18 3:27 PM, Ben Greear wrote:
> While debugging some other problem today on a system using ip rules
> instead of
> VRF, I ran into a case where the remote router was sending back ICMP
> redirects.
>
> That got me thinking...where would these routes get stored in a VRF
> scenario?
>
> Would it magically go to the correct VRF routing table based on the
> incoming interface
> for the ICMP redirect response?
>
Yes. And I expect you to let me know if your mileage varies.
^ permalink raw reply
* Re: KASAN: use-after-free Read in work_is_static_object
From: Eric Biggers @ 2018-05-09 2:49 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, David Miller, Cong Wang, Tom Herbert, Eric Dumazet,
Eric Biggers, netdev, LKML, syzkaller-bugs
In-Reply-To: <CACT4Y+b2SHbAixYaGN-Q3zTBDskafTR6aXSMu=qXtEb4iwco+A@mail.gmail.com>
On Mon, Jan 08, 2018 at 12:58:11PM +0100, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> On Mon, Jan 8, 2018 at 12:55 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> > On Mon, Jan 8, 2018 at 12:43 PM, syzbot
> > <syzbot+40396d275b34b0dd5dad@syzkaller.appspotmail.com> wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> f66faae2f80a45feafc04ce63ef744ac4b6e8c05
> >> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached
> >> Raw console output is attached.
> >> Unfortunately, I don't have any reproducer for this bug yet.
> >>
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+40396d275b34b0dd5dad@syzkaller.appspotmail.com
> >> It will help syzbot understand when the bug is fixed. See footer for
> >> details.
> >> If you forward the report, please keep this part and the footer.
> >
> >
> > This looks like an issue in kcm sockets, so +kcm maintainers.
>
> FTR, guilty file extraction was fixed to ignore kernel/workqueue.c:
> https://github.com/google/syzkaller/commit/1014e5506e35965f3bad13fabb08666134d0b273
> Presumably for bugs in workqueue usually the caller is guilty.
>
>
> >> device ip6_vti0 entered promiscuous mode
> >> ==================================================================
> >> BUG: KASAN: use-after-free in constant_test_bit
> >> arch/x86/include/asm/bitops.h:325 [inline]
> >> BUG: KASAN: use-after-free in work_is_static_object+0x39/0x40
> >> kernel/workqueue.c:443
> >> Read of size 8 at addr ffff8801beca5788 by task syz-executor2/12922
> >>
> >> CPU: 0 PID: 12922 Comm: syz-executor2 Not tainted 4.15.0-rc5+ #178
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:17 [inline]
> >> dump_stack+0x194/0x257 lib/dump_stack.c:53
> >> print_address_description+0x73/0x250 mm/kasan/report.c:252
> >> kasan_report_error mm/kasan/report.c:351 [inline]
> >> kasan_report+0x25b/0x340 mm/kasan/report.c:409
> >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
> >> constant_test_bit arch/x86/include/asm/bitops.h:325 [inline]
> >> work_is_static_object+0x39/0x40 kernel/workqueue.c:443
> >> debug_object_activate+0x36f/0x730 lib/debugobjects.c:470
> >> debug_work_activate kernel/workqueue.c:492 [inline]
> >> __queue_work+0x163/0x1230 kernel/workqueue.c:1381
> >> queue_work_on+0x16a/0x1c0 kernel/workqueue.c:1487
> >> queue_work include/linux/workqueue.h:488 [inline]
> >> strp_check_rcv+0x25/0x30 net/strparser/strparser.c:552
> >> kcm_attach net/kcm/kcmsock.c:1439 [inline]
> >> kcm_attach_ioctl net/kcm/kcmsock.c:1460 [inline]
> >> kcm_ioctl+0x82f/0x1690 net/kcm/kcmsock.c:1665
> >> sock_do_ioctl+0x65/0xb0 net/socket.c:956
> >> sock_ioctl+0x2c2/0x440 net/socket.c:1053
> >> vfs_ioctl fs/ioctl.c:46 [inline]
> >> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> >> SYSC_ioctl fs/ioctl.c:701 [inline]
> >> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> >> entry_SYSCALL_64_fastpath+0x23/0x9a
> >> RIP: 0033:0x452ac9
> >> RSP: 002b:00007f1bbd860c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010
> >> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9
> >> RDX: 0000000020954ff8 RSI: 00000000000089e0 RDI: 0000000000000017
> >> RBP: 000000000000057b R08: 0000000000000000 R09: 0000000000000000
> >> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6428
> >> R13: 00000000ffffffff R14: 00007f1bbd8616d4 R15: 0000000000000000
> >>
> >> Allocated by task 12922:
> >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >> set_track mm/kasan/kasan.c:459 [inline]
> >> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> >> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> >> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
> >> kmem_cache_zalloc include/linux/slab.h:678 [inline]
> >> kcm_attach net/kcm/kcmsock.c:1394 [inline]
> >> kcm_attach_ioctl net/kcm/kcmsock.c:1460 [inline]
> >> kcm_ioctl+0x2d2/0x1690 net/kcm/kcmsock.c:1665
> >> sock_do_ioctl+0x65/0xb0 net/socket.c:956
> >> sock_ioctl+0x2c2/0x440 net/socket.c:1053
> >> vfs_ioctl fs/ioctl.c:46 [inline]
> >> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> >> SYSC_ioctl fs/ioctl.c:701 [inline]
> >> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> >> entry_SYSCALL_64_fastpath+0x23/0x9a
> >>
> >> Freed by task 12929:
> >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >> set_track mm/kasan/kasan.c:459 [inline]
> >> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> >> __cache_free mm/slab.c:3488 [inline]
> >> kmem_cache_free+0x83/0x2a0 mm/slab.c:3746
> >> kcm_unattach+0xe53/0x1510 net/kcm/kcmsock.c:1563
> >> kcm_unattach_ioctl net/kcm/kcmsock.c:1608 [inline]
> >> kcm_ioctl+0xe54/0x1690 net/kcm/kcmsock.c:1675
> >> sock_do_ioctl+0x65/0xb0 net/socket.c:956
> >> sock_ioctl+0x2c2/0x440 net/socket.c:1053
> >> vfs_ioctl fs/ioctl.c:46 [inline]
> >> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> >> SYSC_ioctl fs/ioctl.c:701 [inline]
> >> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> >> entry_SYSCALL_64_fastpath+0x23/0x9a
> >>
> >> The buggy address belongs to the object at ffff8801beca56c0
> >> which belongs to the cache kcm_psock_cache of size 544
> >> The buggy address is located 200 bytes inside of
> >> 544-byte region [ffff8801beca56c0, ffff8801beca58e0)
> >> The buggy address belongs to the page:
> >> page:000000005180a80a count:1 mapcount:0 mapping:0000000058aa9a5c index:0x0
> >> compound_mapcount: 0
> >> flags: 0x2fffc0000008100(slab|head)
> >> raw: 02fffc0000008100 ffff8801beca40c0 0000000000000000 000000010000000b
> >> raw: ffff8801d31e8a48 ffff8801d31e8a48 ffff8801d3f6a380 0000000000000000
> >> page dumped because: kasan: bad access detected
> >>
> >> Memory state around the buggy address:
> >> ffff8801beca5680: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> >> ffff8801beca5700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >>>
> >>> ffff8801beca5780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >>
> >> ^
> >> ffff8801beca5800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ffff8801beca5880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> >> ==================================================================
> >>
> >>
> >> ---
> >> This bug is generated by a dumb bot. It may contain errors.
> >> See https://goo.gl/tpsmEJ for details.
> >> Direct all questions to syzkaller@googlegroups.com.
> >>
> >> syzbot will keep track of this bug report.
> >> If you forgot to add the Reported-by tag, once the fix for this bug is
> >> merged
> >> into any tree, please reply to this email with:
> >> #syz fix: exact-commit-title
This only happened 3 times, with no reproducer, and last occurred 105 days ago
(Jan 23, on commit 2310035fa03f6). It looks *very* similar to
"KASAN: use-after-free Read in get_work_pool"
(https://syzkaller.appspot.com/bug?extid=ea75c0ffcd353d32515f064aaebefc5279e6161e)
which was fixed by commit 2cc683e88c0c99
("kcm: lock lower socket in kcm_attach"),
so I'll make an educated guess and say this one was fixed by that too...
#syz fix: kcm: lock lower socket in kcm_attach
- Eric
^ permalink raw reply
* Re: BUG: spinlock bad magic in tun_do_read
From: Cong Wang @ 2018-05-09 2:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: syzbot, David Miller, Eric Dumazet, Jason Wang, LKML,
Michael S. Tsirkin, Linux Kernel Network Developers, Petar Penkov,
Sabrina Dubroca, syzkaller-bugs
In-Reply-To: <997afbee-1e89-aa5b-5b15-cad5a073cc38@gmail.com>
On Mon, May 7, 2018 at 11:04 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 05/07/2018 10:54 PM, Cong Wang wrote:
>>
>> Yeah, we should return early before hitting this uninitialized ptr ring...
>> Something like:
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index ef33950a45d9..638c87a95247 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -2128,6 +2128,9 @@ static void *tun_ring_recv(struct tun_file
>> *tfile, int noblock, int *err)
>> void *ptr = NULL;
>> int error = 0;
>>
>> + if (!tfile->tx_ring.queue)
>> + goto out;
>> +
>>
>> Or, checking if tun is detached...
>>
>>
>
> tx_ring was properly initialized when first ptr_ring_consume() at line 2131 was attempted.
>
> The bug happens later at line 2143 , after a schedule() call, line 2155
>
> So a single check at function prologue wont solve the case the thread had to sleep,
> then some uninit happened.
Very good point. RTNL lock is supposed to protect cleanup path, but I don't
think we can acquire RTNL for tun_chr_read_iter() path...
^ permalink raw reply
* Re: [PATCH net] r8169: fix powering up RTL8168h
From: David Miller @ 2018-05-09 2:55 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, ojab, netdev
In-Reply-To: <ff344a31-4cb8-1e49-7b5e-3a729125444b@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 7 May 2018 21:11:21 +0200
> Since commit a92a08499b1f "r8169: improve runtime pm in general and
> suspend unused ports" interfaces w/o link are runtime-suspended after
> 10s. On systems where drivers take longer to load this can lead to the
> situation that the interface is runtime-suspended already when it's
> initially brought up.
> This shouldn't be a problem because rtl_open() resumes MAC/PHY.
> However with at least one chip version the interface doesn't properly
> come up, as reported here:
> https://bugzilla.kernel.org/show_bug.cgi?id=199549
>
> The vendor driver uses a delay to give certain chip versions some
> time to resume before starting the PHY configuration. So let's do
> the same. I don't know which chip versions may be affected,
> therefore apply this delay always.
>
> This patch was reported to fix the issue for RTL8168h.
> I was able to reproduce the issue on an Asus H310I-Plus which also
> uses a RTL8168h. Also in my case the patch fixed the issue.
>
> Reported-by: Slava Kardakov <ojab@ojab.ru>
> Tested-by: Slava Kardakov <ojab@ojab.ru>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied and queued up for -stable.
> This patch will not apply to net-next as it conflicts with other
> changes which have been done in the meantime. So I'll send a
> separate patch for net-next.
That's fine, I'll deal with it when I next merge net into net-next.
Sending another copy of this patch for net-next is not the way to deal
with this. Just make me aware of the impending complict and I will
resolve it when I see it.
Thanks.
^ permalink raw reply
* [PATCH net-next] net: dsa: fix added_by_user switchdev notification
From: Vivien Didelot @ 2018-05-09 3:03 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, Vivien Didelot, Petr Machata, jiri, idosch,
ivecera, davem, stephen, andrew, f.fainelli, nikolay, bridge
Commit 161d82de1ff8 ("net: bridge: Notify about !added_by_user FDB
entries") causes the below oops when bringing up a slave interface,
because dsa_port_fdb_add is still scheduled, but with a NULL address.
To fix this, keep the dsa_slave_switchdev_event function agnostic of the
notified info structure and handle the added_by_user flag in the
specific dsa_slave_switchdev_event_work function.
[ 75.512263] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 75.519063] pgd = (ptrval)
[ 75.520545] [00000000] *pgd=00000000
[ 75.522839] Internal error: Oops: 17 [#1] ARM
[ 75.525898] Modules linked in:
[ 75.527673] CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 4.17.0-rc2 #78
[ 75.532988] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
[ 75.538153] Workqueue: dsa_ordered dsa_slave_switchdev_event_work
[ 75.542970] PC is at mv88e6xxx_port_db_load_purge+0x60/0x1b0
[ 75.547341] LR is at mdiobus_read_nested+0x6c/0x78
[ 75.550833] pc : [<804cd5c0>] lr : [<804bba84>] psr: 60070013
[ 75.555796] sp : 9f54bd78 ip : 9f54bd87 fp : 9f54bddc
[ 75.559719] r10: 00000000 r9 : 0000000e r8 : 9f6a6010
[ 75.563643] r7 : 00000000 r6 : 81203048 r5 : 9f6a6010 r4 : 9f6a601c
[ 75.568867] r3 : 00000000 r2 : 00000000 r1 : 0000000d r0 : 00000000
[ 75.574094] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 75.579933] Control: 10c53c7d Table: 9de20059 DAC: 00000051
[ 75.584384] Process kworker/u2:1 (pid: 9, stack limit = 0x(ptrval))
[ 75.589349] Stack: (0x9f54bd78 to 0x9f54c000)
[ 75.592406] bd60: 00000000 00000000
[ 75.599295] bd80: 00000391 9f299d10 9f299d68 8014317c 9f7f0000 8120af00 00006dc2 00000000
[ 75.606186] bda0: 8120af00 00000000 9f54bdec 1c9f5d92 8014317c 9f6a601c 9f6a6010 00000000
[ 75.613076] bdc0: 00000000 00000000 9dd1141c 8125a0b4 9f54be0c 9f54bde0 804cd8a8 804cd56c
[ 75.619966] bde0: 0000000e 80143680 00000001 9dce9c1c 81203048 9dce9c10 00000003 00000000
[ 75.626858] be00: 9f54be5c 9f54be10 806abcac 804cd864 9f54be54 80143664 8014317c 80143054
[ 75.633748] be20: ffcaa81d 00000000 812030b0 1c9f5d92 00000000 81203048 9f54beb4 00000003
[ 75.640639] be40: ffffffff 00000000 9dd1141c 8125a0b4 9f54be84 9f54be60 80138e98 806abb18
[ 75.647529] be60: 81203048 9ddc4000 9dce9c54 9f72a300 00000000 00000000 9f54be9c 9f54be88
[ 75.654420] be80: 801390bc 80138e50 00000000 9dce9c54 9f54beac 9f54bea0 806a9524 801390a0
[ 75.661310] bea0: 9f54bedc 9f54beb0 806a9c7c 806a950c 9f54becc 00000000 00000000 00000000
[ 75.668201] bec0: 9f540000 1c9f5d92 805fe604 9ddffc00 9f54befc 9f54bee0 806ab228 806a9c38
[ 75.675092] bee0: 806ab178 9ddffc00 9f4c1900 9f40d200 9f54bf34 9f54bf00 80131e30 806ab184
[ 75.681983] bf00: 9f40d214 9f54a038 9f40d200 9f40d200 9f4c1918 812119a0 9f40d214 9f54a038
[ 75.688873] bf20: 9f40d200 9f4c1900 9f54bf7c 9f54bf38 80132124 80131d1c 9f5f2dd8 00000000
[ 75.695764] bf40: 812119a0 9f54a038 812119a0 81259c5b 9f5f2dd8 9f5f2dc0 9f53dbc0 00000000
[ 75.702655] bf60: 9f4c1900 801320b4 9f5f2dd8 9f4f7e88 9f54bfac 9f54bf80 80137ad0 801320c0
[ 75.709544] bf80: 9f54a000 9f53dbc0 801379a0 00000000 00000000 00000000 00000000 00000000
[ 75.716434] bfa0: 00000000 9f54bfb0 801010e8 801379ac 00000000 00000000 00000000 00000000
[ 75.723324] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 75.730206] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 75.737083] Backtrace:
[ 75.738252] [<804cd560>] (mv88e6xxx_port_db_load_purge) from [<804cd8a8>] (mv88e6xxx_port_fdb_add+0x50/0x68)
[ 75.746795] r10:8125a0b4 r9:9dd1141c r8:00000000 r7:00000000 r6:00000000 r5:9f6a6010
[ 75.753323] r4:9f6a601c
[ 75.754570] [<804cd858>] (mv88e6xxx_port_fdb_add) from [<806abcac>] (dsa_switch_event+0x1a0/0x660)
[ 75.762238] r8:00000000 r7:00000003 r6:9dce9c10 r5:81203048 r4:9dce9c1c
[ 75.767655] [<806abb0c>] (dsa_switch_event) from [<80138e98>] (notifier_call_chain+0x54/0x94)
[ 75.774893] r10:8125a0b4 r9:9dd1141c r8:00000000 r7:ffffffff r6:00000003 r5:9f54beb4
[ 75.781423] r4:81203048
[ 75.782672] [<80138e44>] (notifier_call_chain) from [<801390bc>] (raw_notifier_call_chain+0x28/0x30)
[ 75.790514] r9:00000000 r8:00000000 r7:9f72a300 r6:9dce9c54 r5:9ddc4000 r4:81203048
[ 75.796982] [<80139094>] (raw_notifier_call_chain) from [<806a9524>] (dsa_port_notify+0x24/0x38)
[ 75.804483] [<806a9500>] (dsa_port_notify) from [<806a9c7c>] (dsa_port_fdb_add+0x50/0x6c)
[ 75.811371] [<806a9c2c>] (dsa_port_fdb_add) from [<806ab228>] (dsa_slave_switchdev_event_work+0xb0/0x10c)
[ 75.819635] r4:9ddffc00
[ 75.820885] [<806ab178>] (dsa_slave_switchdev_event_work) from [<80131e30>] (process_one_work+0x120/0x3a4)
[ 75.829241] r6:9f40d200 r5:9f4c1900 r4:9ddffc00 r3:806ab178
[ 75.833612] [<80131d10>] (process_one_work) from [<80132124>] (worker_thread+0x70/0x574)
[ 75.840415] r10:9f4c1900 r9:9f40d200 r8:9f54a038 r7:9f40d214 r6:812119a0 r5:9f4c1918
[ 75.846945] r4:9f40d200
[ 75.848191] [<801320b4>] (worker_thread) from [<80137ad0>] (kthread+0x130/0x160)
[ 75.854300] r10:9f4f7e88 r9:9f5f2dd8 r8:801320b4 r7:9f4c1900 r6:00000000 r5:9f53dbc0
[ 75.860830] r4:9f5f2dc0
[ 75.862076] [<801379a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
[ 75.867999] Exception stack(0x9f54bfb0 to 0x9f54bff8)
[ 75.871753] bfa0: 00000000 00000000 00000000 00000000
[ 75.878640] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 75.885519] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 75.890844] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801379a0
[ 75.897377] r4:9f53dbc0 r3:9f54a000
[ 75.899663] Code: e3a02000 e3a03000 e14b26f4 e24bc055 (e5973000)
[ 75.904575] ---[ end trace fbca818a124dbf0d ]---
Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications")
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
@petr I expect the same issue with Rocker, but I haven't tested it.
net/dsa/slave.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index c287f1ef964c..746ab428a17a 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1395,6 +1395,9 @@ static void dsa_slave_switchdev_event_work(struct work_struct *work)
switch (switchdev_work->event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE:
fdb_info = &switchdev_work->fdb_info;
+ if (!fdb_info->added_by_user)
+ break;
+
err = dsa_port_fdb_add(dp, fdb_info->addr, fdb_info->vid);
if (err) {
netdev_dbg(dev, "fdb add failed err=%d\n", err);
@@ -1406,6 +1409,9 @@ static void dsa_slave_switchdev_event_work(struct work_struct *work)
case SWITCHDEV_FDB_DEL_TO_DEVICE:
fdb_info = &switchdev_work->fdb_info;
+ if (!fdb_info->added_by_user)
+ break;
+
err = dsa_port_fdb_del(dp, fdb_info->addr, fdb_info->vid);
if (err) {
netdev_dbg(dev, "fdb del failed err=%d\n", err);
@@ -1441,7 +1447,6 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
- struct switchdev_notifier_fdb_info *fdb_info = ptr;
struct dsa_switchdev_event_work *switchdev_work;
if (!dsa_slave_dev_check(dev))
@@ -1459,10 +1464,7 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
switch (event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
case SWITCHDEV_FDB_DEL_TO_DEVICE:
- if (!fdb_info->added_by_user)
- break;
- if (dsa_slave_switchdev_fdb_work_init(switchdev_work,
- fdb_info))
+ if (dsa_slave_switchdev_fdb_work_init(switchdev_work, ptr))
goto err_fdb_work_init;
dev_hold(dev);
break;
--
2.17.0
^ permalink raw reply related
* Re: BUG: spinlock bad magic in tun_do_read
From: Jason Wang @ 2018-05-09 3:38 UTC (permalink / raw)
To: Cong Wang, Eric Dumazet
Cc: syzbot, David Miller, Eric Dumazet, LKML, Michael S. Tsirkin,
Linux Kernel Network Developers, Petar Penkov, Sabrina Dubroca,
syzkaller-bugs
In-Reply-To: <CAM_iQpW+vrecKuWTJ+zHt11ge7xPRWt=4GmZJxJ5Ffp_awV-ag@mail.gmail.com>
On 2018年05月09日 10:50, Cong Wang wrote:
> On Mon, May 7, 2018 at 11:04 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>> On 05/07/2018 10:54 PM, Cong Wang wrote:
>>> Yeah, we should return early before hitting this uninitialized ptr ring...
>>> Something like:
>>>
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index ef33950a45d9..638c87a95247 100644
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -2128,6 +2128,9 @@ static void *tun_ring_recv(struct tun_file
>>> *tfile, int noblock, int *err)
>>> void *ptr = NULL;
>>> int error = 0;
>>>
>>> + if (!tfile->tx_ring.queue)
>>> + goto out;
>>> +
>>>
>>> Or, checking if tun is detached...
>>>
>>>
>> tx_ring was properly initialized when first ptr_ring_consume() at line 2131 was attempted.
>>
>> The bug happens later at line 2143 , after a schedule() call, line 2155
>>
>> So a single check at function prologue wont solve the case the thread had to sleep,
>> then some uninit happened.
>
> Very good point. RTNL lock is supposed to protect cleanup path, but I don't
> think we can acquire RTNL for tun_chr_read_iter() path...
I think the root cause is we try to initialize ptr ring during TUNSETIFF
since the length depends on the dev->tx_queue_len and try to destroy it
when device is gone. We can solve this by initializing a zero size
ptr_ring during open() and resize if necessary. Then there no need for
any workaround like memset and checking against NULL.
Let me try to cook a patch for this.
Thanks
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Jason Wang @ 2018-05-09 3:43 UTC (permalink / raw)
To: Tiwei Bie
Cc: Michael S. Tsirkin, virtualization, linux-kernel, netdev, wexu,
jfreimann
In-Reply-To: <20180508094406.qjlaism3hqy4hvjd@debian>
On 2018年05月08日 17:44, Tiwei Bie wrote:
> On Tue, May 08, 2018 at 05:34:40PM +0800, Jason Wang wrote:
>> On 2018年05月08日 17:16, Tiwei Bie wrote:
>>> On Tue, May 08, 2018 at 03:16:53PM +0800, Jason Wang wrote:
>>>> On 2018年05月08日 14:44, Tiwei Bie wrote:
>>>>> On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
>>>>>> On 2018年05月08日 11:05, Jason Wang wrote:
>>>>>>>> Because in virtqueue_enable_cb_delayed(), we may set an
>>>>>>>> event_off which is bigger than new and both of them have
>>>>>>>> wrapped. And in this case, although new is smaller than
>>>>>>>> event_off (i.e. the third param -- old), new shouldn't
>>>>>>>> add vq->num, and actually we are expecting a very big
>>>>>>>> idx diff.
>>>>>>> Yes, so to calculate distance correctly between event and new, we just
>>>>>>> need to compare the warp counter and return false if it doesn't match
>>>>>>> without the need to try to add vq.num here.
>>>>>>>
>>>>>>> Thanks
>>>>>> Sorry, looks like the following should work, we need add vq.num if
>>>>>> used_wrap_counter does not match:
>>>>>>
>>>>>> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>>>>>> __u16 off_wrap, __u16 new,
>>>>>> __u16 old)
>>>>>> {
>>>>>> bool wrap = off_wrap >> 15;
>>>>>> int off = off_wrap & ~(1 << 15);
>>>>>> __u16 d1, d2;
>>>>>>
>>>>>> if (wrap != vq->used_wrap_counter)
>>>>>> d1 = new + vq->num - off - 1;
>>>>> Just to draw your attention (maybe you have already
>>>>> noticed this).
>>>> I miss this, thanks!
>>>>
>>>>> In this case (i.e. wrap != vq->used_wrap_counter),
>>>>> it's also possible that (off < new) is true. Because,
>>>>>
>>>>> when virtqueue_enable_cb_delayed_packed() is used,
>>>>> `off` is calculated in driver in a way like this:
>>>>>
>>>>> off = vq->last_used_idx + bufs;
>>>>> if (off >= vq->vring_packed.num) {
>>>>> off -= vq->vring_packed.num;
>>>>> wrap_counter ^= 1;
>>>>> }
>>>>>
>>>>> And when `new` (in vhost) is close to vq->num. The
>>>>> vq->last_used_idx + bufs (in driver) can be bigger
>>>>> than vq->vring_packed.num, and:
>>>>>
>>>>> 1. `off` will wrap;
>>>>> 2. wrap counters won't match;
>>>>> 3. off < new;
>>>>>
>>>>> And d1 (i.e. new + vq->num - off - 1) will be a value
>>>>> bigger than vq->num. I'm okay with this, although it's
>>>>> a bit weird.
>>>> So I'm considering something more compact by reusing vring_need_event() by
>>>> pretending a larger queue size and adding vq->num back when necessary:
>>>>
>>>> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>>>> __u16 off_wrap, __u16 new,
>>>> __u16 old)
>>>> {
>>>> bool wrap = vq->used_wrap_counter;
>>> If the wrap counter is obtained from the vq,
>>> I think `new` should also be obtained from
>>> the vq. Or the wrap counter should be carried
>>> in `new`.
>>>
>>>> int off = off_wrap & ~(1 << 15);
>>>> __u16 d1, d2;
>>>>
>>>> if (new < old) {
>>>> new += vq->num;
>>>> wrap ^= 1;
>>>> }
>>>>
>>>> if (wrap != off_wrap >> 15)
>>>> off += vq->num;
>>> When `new` and `old` wraps, and `off` doesn't wrap,
>>> wrap != (off_wrap >> 15) will be true. In this case,
>>> `off` is bigger than `new`, and what we should do
>>> is `off -= vq->num` instead of `off += vq->num`.
>> If I understand this correctly, if we track old correctly, it won't happen
>> if guest driver behave correctly. That means it should only happen for a
>> buggy driver (e.g trying to move off_wrap back).
> If vhost is faster than virtio driver, I guess above
> case may happen. The `old` and `new` will be updated
> each time we want to notify the driver. If the driver
> is slower, `old` and `new` in vhost may wrap before
> the `off` which is set by driver wraps.
>
> Best regards,
> Tiwei Bie
>
Oh, right.
But the code still work (in this case new - event_idx - 1 will
underflow). (And I admit it still looks ugly).
Thanks
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2018-05-09 4:12 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Eric Dumazet,
Boris Pismenny
[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/tls/tls_main.c
between commit:
98f0a39529e5 ("tls: fix use after free in tls_sk_proto_close")
from the net tree and commit:
f66de3ee2c16 ("net/tls: Split conf to rx + tx")
from the net-next tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/tls/tls_main.c
index 20cd93be6236,4b57ddd72f34..000000000000
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@@ -254,8 -252,12 +254,9 @@@ static void tls_sk_proto_close(struct s
lock_sock(sk);
sk_proto_close = ctx->sk_proto_close;
- if (ctx->conf == TLS_BASE || ctx->conf == TLS_HW_RECORD) {
- if (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)
- goto skip_tx_cleanup;
-
- if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) {
- kfree(ctx);
- ctx = NULL;
++ if ((ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) ||
++ (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)) {
+ free_ctx = true;
goto skip_tx_cleanup;
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2018-05-09 4:19 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Anders Roxell
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/net/Makefile
between commit:
1751eb42ddb5 ("selftests: net: use TEST_PROGS_EXTENDED")
from the net tree and commits:
a7b15ab887e5 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/net/Makefile
index 3ff81a478dbe,73af45773938..000000000000
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,10 -5,13 +5,13 @@@ CFLAGS = -Wall -Wl,--no-as-needed -O2
CFLAGS += -I../../../../usr/include/
TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
+ TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
-TEST_GEN_PROGS_EXTENDED := in_netns.sh
+TEST_PROGS_EXTENDED := in_netns.sh
TEST_GEN_FILES = socket
TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap tcp_inq
+ TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx
TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the bpf-next tree with the s390 tree
From: Stephen Rothwell @ 2018-05-09 4:21 UTC (permalink / raw)
To: Networking, Martin Schwidefsky, Heiko Carstens, David Miller
Cc: Daniel Borkmann, Alexei Starovoitov, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <20180508102638.1e19b7f2@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
Hi all,
On Tue, 8 May 2018 10:26:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> arch/s390/net/bpf_jit.S
>
> between commit:
>
> de5cb6eb514e ("s390: use expoline thunks in the BPF JIT")
>
> from the s390 tree and commit:
>
> e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")
>
> from the bpf-next tree.
>
> I fixed it up (I just removed the file as the latter does) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
This is now a conflict between the net-next and s390 trees.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: KASAN: use-after-free Read in ip6_xmit
From: Eric Biggers @ 2018-05-09 4:38 UTC (permalink / raw)
To: syzbot
Cc: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji,
Boris Pismenny
In-Reply-To: <001a113ee06a9a5d3b0561f1342d@google.com>
On Thu, Jan 04, 2018 at 02:58:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+56029fd3642567f395f0@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1514737122.010:7): avc: denied { map } for
> pid=3153 comm="syzkaller920384" path="/root/syzkaller920384627" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==================================================================
> BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:189
> [inline]
> BUG: KASAN: use-after-free in ip6_xmit+0x1f92/0x1fc0
> net/ipv6/ip6_output.c:248
> Read of size 8 at addr ffff8801ca6f9f18 by task syzkaller920384/3153
>
> CPU: 1 PID: 3153 Comm: syzkaller920384 Not tainted 4.15.0-rc4-next-20171221+
> #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x25b/0x340 mm/kasan/report.c:409
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
> ip6_dst_idev include/net/ip6_fib.h:189 [inline]
> ip6_xmit+0x1f92/0x1fc0 net/ipv6/ip6_output.c:248
> inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
> tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
> tcp_send_syn_data net/ipv4/tcp_output.c:3456 [inline]
> tcp_connect+0x1ed5/0x4090 net/ipv4/tcp_output.c:3495
> tcp_v4_connect+0x15ef/0x1e70 net/ipv4/tcp_ipv4.c:257
> __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620
> tcp_sendmsg_fastopen net/ipv4/tcp.c:1167 [inline]
> tcp_sendmsg_locked+0x27e4/0x3b30 net/ipv4/tcp.c:1212
> tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1459
> inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
> sock_sendmsg_nosec net/socket.c:628 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:638
> SYSC_sendto+0x361/0x5c0 net/socket.c:1719
> SyS_sendto+0x40/0x50 net/socket.c:1687
> entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x43fda9
> RSP: 002b:00007ffc9b8bd818 EFLAGS: 00000217 ORIG_RAX: 000000000000002c
> RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 000000000043fda9
> RDX: 0000000000000000 RSI: 0000000020aa1000 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 0000000020aa1000 R09: 0000000000000010
> R10: 0000000023ffffff R11: 0000000000000217 R12: 0000000000401710
> R13: 00000000004017a0 R14: 0000000000000000 R15: 0000000000000000
>
> Allocated by task 3140:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3545
> dst_alloc+0x11f/0x1a0 net/core/dst.c:104
> rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1500
> __mkroute_output net/ipv4/route.c:2242 [inline]
> ip_route_output_key_hash_rcu+0xa40/0x2c10 net/ipv4/route.c:2470
> ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2299
> __ip_route_output_key include/net/route.h:125 [inline]
> ip_route_connect include/net/route.h:300 [inline]
> __ip4_datagram_connect+0xa67/0x1240 net/ipv4/datagram.c:51
> __ip6_datagram_connect+0x709/0xf90 net/ipv6/datagram.c:157
> ip6_datagram_connect+0x2f/0x50 net/ipv6/datagram.c:274
> inet_dgram_connect+0x16b/0x1f0 net/ipv4/af_inet.c:542
> SYSC_connect+0x213/0x4a0 net/socket.c:1611
> SyS_connect+0x24/0x30 net/socket.c:1592
> entry_SYSCALL_64_fastpath+0x1f/0x96
>
> Freed by task 0:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> __cache_free mm/slab.c:3489 [inline]
> kmem_cache_free+0x83/0x2a0 mm/slab.c:3747
> dst_destroy+0x219/0x310 net/core/dst.c:140
> dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
> __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
> rcu_do_batch kernel/rcu/tree.c:2675 [inline]
> invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
> __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
> rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>
> The buggy address belongs to the object at ffff8801ca6f9f00
> which belongs to the cache ip_dst_cache of size 168
> The buggy address is located 24 bytes inside of
> 168-byte region [ffff8801ca6f9f00, ffff8801ca6f9fa8)
> The buggy address belongs to the page:
> page:00000000637e5443 count:1 mapcount:0 mapping:0000000000ddf2d5
> index:0xffff8801ca6f9000
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801ca6f9000 ffff8801ca6f9000 000000010000000a
> raw: ffff8801d794f138 ffffea0007515320 ffff8801d6d724c0 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801ca6f9e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801ca6f9e80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
> > ffff8801ca6f9f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8801ca6f9f80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
> ffff8801ca6fa000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
No longer reproducible, seems to have first fixed by commit d91c3e17f75f21
("net/tls: Only attach to sockets in ESTABLISHED state"), but commit
c113187d38ff85d ("tls: Use correct sk->sk_prot for IPV6") also appears related.
That fixes it too if I revert the first commit, and the KASAN report indicates
that an 'struct rtable' (IPv4-related) was accessed as if it were an
'struct rt6_info' (IPv6-related). So telling syzbot:
#syz fix: tls: Use correct sk->sk_prot for IPV6
I also had simplified this reproducer a bit, so I'm pasting it below in case
anyone still wants it:
#include <netinet/in.h>
#include <unistd.h>
#define SOL_TCP 6
#define TCP_ULP 31
int main()
{
int tcp_fd;
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_port = htobe16(0x4e22),
.sin_addr = { htobe32(0x7f000001) }
};
tcp_fd = socket(AF_INET6, SOCK_STREAM, 0);
setsockopt(tcp_fd, SOL_TCP, TCP_ULP, "tls", 4);
sendto(tcp_fd, NULL, 0, MSG_FASTOPEN, (void *)&addr, sizeof(addr));
}
- Eric
^ permalink raw reply
* Re: KASAN: out-of-bounds Read in ip6_xmit
From: Eric Biggers @ 2018-05-09 4:45 UTC (permalink / raw)
To: syzbot
Cc: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji,
Paolo Abeni
In-Reply-To: <001a11433bee67ed4c0563db12f9@google.com>
On Sun, Jan 28, 2018 at 11:24:01AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on net-next commit
> 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +0000)
> Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed'
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c8e66da874feb11aaca6@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> ==================================================================
> BUG: KASAN: out-of-bounds in ip6_dst_idev include/net/ip6_fib.h:192 [inline]
> BUG: KASAN: out-of-bounds in ip6_xmit+0x1f76/0x2260
> net/ipv6/ip6_output.c:264
> Read of size 8 at addr ffff8801bcc8cc18 by task syz-executor2/11459
>
> CPU: 0 PID: 11459 Comm: syz-executor2 Not tainted 4.15.0-rc9+ #212
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x25b/0x340 mm/kasan/report.c:409
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
> ip6_dst_idev include/net/ip6_fib.h:192 [inline]
> ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
> inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
> l2tp_xmit_core net/l2tp/l2tp_core.c:1096 [inline]
> l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1191
> pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
> sock_sendmsg_nosec net/socket.c:630 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:640
> ___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
> __sys_sendmsg+0xe5/0x210 net/socket.c:2080
> SYSC_sendmsg net/socket.c:2091 [inline]
> SyS_sendmsg+0x2d/0x50 net/socket.c:2087
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x453299
> RSP: 002b:00007fcfef194c58 EFLAGS: 00000212 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 000000000071bf58 RCX: 0000000000453299
> RDX: 0000000000000081 RSI: 000000002037ffc8 RDI: 0000000000000014
> RBP: 000000000000036f R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f4308
> R13: 00000000ffffffff R14: 00007fcfef1956d4 R15: 000000000000000b
>
> Allocated by task 11466:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
> dst_alloc+0x11f/0x1a0 net/core/dst.c:104
> rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1497
> ip_route_input_slow net/ipv4/route.c:2006 [inline]
> ip_route_input_rcu+0x1076/0x3200 net/ipv4/route.c:2137
> ip_route_input_noref+0xf5/0x1e0 net/ipv4/route.c:2083
> ip_rcv_finish+0x3a6/0x2040 net/ipv4/ip_input.c:348
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_rcv+0xc5a/0x1840 net/ipv4/ip_input.c:493
> __netif_receive_skb_core+0x1a41/0x3460 net/core/dev.c:4547
> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4612
> netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4686
> netif_receive_skb+0xae/0x390 net/core/dev.c:4710
> tun_rx_batched.isra.53+0x5ee/0x870 drivers/net/tun.c:1558
> tun_get_user+0x25de/0x3940 drivers/net/tun.c:1958
> tun_chr_write_iter+0xb9/0x160 drivers/net/tun.c:1986
> call_write_iter include/linux/fs.h:1772 [inline]
> do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
> do_iter_write+0x154/0x540 fs/read_write.c:932
> vfs_writev+0x18a/0x340 fs/read_write.c:977
> do_writev+0xfc/0x2a0 fs/read_write.c:1012
> SYSC_writev fs/read_write.c:1085 [inline]
> SyS_writev+0x27/0x30 fs/read_write.c:1082
> entry_SYSCALL_64_fastpath+0x29/0xa0
>
> Freed by task 7176:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> __cache_free mm/slab.c:3488 [inline]
> kmem_cache_free+0x83/0x2a0 mm/slab.c:3746
> dst_destroy+0x257/0x370 net/core/dst.c:140
> dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
> __rcu_reclaim kernel/rcu/rcu.h:195 [inline]
> rcu_do_batch kernel/rcu/tree.c:2758 [inline]
> invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
> __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
> rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2996
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>
> The buggy address belongs to the object at ffff8801bcc8cc00
> which belongs to the cache ip_dst_cache of size 168
> The buggy address is located 24 bytes inside of
> 168-byte region [ffff8801bcc8cc00, ffff8801bcc8cca8)
> The buggy address belongs to the page:
> page:ffffea0006f32300 count:1 mapcount:0 mapping:ffff8801bcc8c000 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801bcc8c000 0000000000000000 0000000100000010
> raw: ffffea00074da720 ffffea000743cb20 ffff8801d6fe34c0 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801bcc8cb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801bcc8cb80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
> > ffff8801bcc8cc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
> ffff8801bcc8cc80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
> ffff8801bcc8cd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
No reproducer and last occurred 58 days ago (on commit f44b1886a5f876c8).
Probably was fixed by commit b954f94023dcc61:
#syz fix: l2tp: fix races with ipv4-mapped ipv6 addresses
- Eric
^ permalink raw reply
* linux-next: build warning after merge of the bpf-next tree
From: Stephen Rothwell @ 2018-05-09 4:49 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Ahern
[-- Attachment #1: Type: text/plain, Size: 2854 bytes --]
Hi all,
After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/dma-mapping.h:5:0,
from include/linux/skbuff.h:34,
from include/linux/if_ether.h:23,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/perf_event.h:57,
from include/linux/trace_events.h:10,
from include/trace/trace_events.h:20,
from include/trace/define_trace.h:96,
from drivers/android/binder_trace.h:387,
from drivers/android/binder.c:5702:
include/linux/sizes.h:24:0: warning: "SZ_1K" redefined
#define SZ_1K 0x00000400
drivers/android/binder.c:116:0: note: this is the location of the previous definition
#define SZ_1K 0x400
In file included from include/linux/dma-mapping.h:5:0,
from include/linux/skbuff.h:34,
from include/linux/if_ether.h:23,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/perf_event.h:57,
from include/linux/trace_events.h:10,
from include/trace/trace_events.h:20,
from include/trace/define_trace.h:96,
from drivers/android/binder_trace.h:387,
from drivers/android/binder.c:5702:
include/linux/sizes.h:37:0: warning: "SZ_4M" redefined
#define SZ_4M 0x00400000
drivers/android/binder.c:120:0: note: this is the location of the previous definition
#define SZ_4M 0x400000
fs/ecryptfs/miscdev.c:206:0: warning: "PKT_TYPE_OFFSET" redefined
#define PKT_TYPE_OFFSET 0
In file included from include/linux/if_ether.h:23:0,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/writeback.h:183,
from include/linux/backing-dev.h:16,
from fs/ecryptfs/ecryptfs_kernel.h:41,
from fs/ecryptfs/miscdev.c:30:
include/linux/skbuff.h:753:0: note: this is the location of the previous definition
#define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)
Introduced by commit
9c38f3c8b153 ("bpf: Provide helper to do forwarding lookups in kernel FIB table")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Eric Biggers @ 2018-05-09 5:05 UTC (permalink / raw)
To: dccp, Gerrit Renker
Cc: syzbot, davem, garsilva, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000fedad9056b7f07ce@google.com>
On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de47800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde7800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141b4be7800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+99858724c0ba555a12ea@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
> sk_backlog_rcv include/net/sock.h:909 [inline]
> __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
> dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
> ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
> __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> process_backlog+0x219/0x760 net/core/dev.c:5337
> napi_poll net/core/dev.c:5735 [inline]
> net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
> </IRQ>
> do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
> do_softirq arch/x86/include/asm/preempt.h:23 [inline]
> __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
> local_bh_enable include/linux/bottom_half.h:32 [inline]
> rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
> ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
> ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
> NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
> dst_output include/net/dst.h:444 [inline]
> ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
> ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
> dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
> dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
> dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
> dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> ___sys_sendmsg+0x525/0x940 net/socket.c:2117
> __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
> __do_sys_sendmmsg net/socket.c:2241 [inline]
> __se_sys_sendmmsg net/socket.c:2238 [inline]
> __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x445d09
> RSP: 002b:00007f3c7eff5d88 EFLAGS: 00000293 ORIG_RAX: 0000000000000133
> RAX: ffffffffffffffda RBX: 00000000006dac40 RCX: 0000000000445d09
> RDX: 0000000000000001 RSI: 000000
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
There's already a bug report with this title, this one just had a few characters
truncated from the end. Dmitry, is that intentional? The other one is
https://groups.google.com/forum/#!msg/syzkaller-bugs/u5nq3PdPkIc/bBFjKHXPAgAJ:
#syz dup: BUG: please report to dc...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Anyway, this is apparently a DCCP bug, and as I posted on the other thread it's
easily reproducible with the following program. Gerrit, are you still the DCCP
maintainer, or is the MAINTAINERS file outdated?
#include <linux/dccp.h>
#include <linux/in.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <unistd.h>
int main()
{
struct sockaddr_in addr = { .sin_family = AF_INET };
socklen_t addrlen = sizeof(addr);
int fd;
while (fork())
wait(NULL);
fd = socket(AF_INET, SOCK_DCCP, 0);
bind(fd, (void *)&addr, addrlen);
getsockname(fd, (void *)&addr, &addrlen);
listen(fd, 100);
if (fork()) {
fd = socket(AF_INET, SOCK_DCCP, 0);
setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_CCID, "\x03", 1);
connect(fd, (void *)&addr, sizeof(addr));
} else {
fd = accept(fd, NULL, 0);
}
for (int i = 0; i < 1000; i++)
write(fd, "X", 1);
}
- Eric
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Dmitry Vyukov @ 2018-05-09 5:23 UTC (permalink / raw)
To: Eric Biggers
Cc: dccp, Gerrit Renker, syzbot, David Miller, Gustavo A . R . Silva,
LKML, netdev, syzkaller-bugs
In-Reply-To: <20180509050509.GE711@sol.localdomain>
On Wed, May 9, 2018 at 7:05 AM, Eric Biggers <ebiggers3@gmail.com> wrote:
> On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de47800000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
>> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde7800000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141b4be7800000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+99858724c0ba555a12ea@syzkaller.appspotmail.com
>>
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at
>> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
>> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> <IRQ>
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
>> net/dccp/ccids/lib/packet_history.c:422
>> ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
>> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
>> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
>> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
>> sk_backlog_rcv include/net/sock.h:909 [inline]
>> __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
>> dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
>> ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
>> NF_HOOK include/linux/netfilter.h:288 [inline]
>> ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
>> dst_input include/net/dst.h:450 [inline]
>> ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
>> NF_HOOK include/linux/netfilter.h:288 [inline]
>> ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
>> __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
>> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
>> process_backlog+0x219/0x760 net/core/dev.c:5337
>> napi_poll net/core/dev.c:5735 [inline]
>> net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
>> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
>> </IRQ>
>> do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
>> do_softirq arch/x86/include/asm/preempt.h:23 [inline]
>> __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
>> local_bh_enable include/linux/bottom_half.h:32 [inline]
>> rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
>> ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
>> ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
>> NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>> ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
>> dst_output include/net/dst.h:444 [inline]
>> ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
>> ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
>> dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
>> dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
>> dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
>> dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
>> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
>> sock_sendmsg_nosec net/socket.c:629 [inline]
>> sock_sendmsg+0xd5/0x120 net/socket.c:639
>> ___sys_sendmsg+0x525/0x940 net/socket.c:2117
>> __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
>> __do_sys_sendmmsg net/socket.c:2241 [inline]
>> __se_sys_sendmmsg net/socket.c:2238 [inline]
>> __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
>> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x445d09
>> RSP: 002b:00007f3c7eff5d88 EFLAGS: 00000293 ORIG_RAX: 0000000000000133
>> RAX: ffffffffffffffda RBX: 00000000006dac40 RCX: 0000000000445d09
>> RDX: 0000000000000001 RSI: 000000
>>
>>
>> ---
>> This bug is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>
> There's already a bug report with this title, this one just had a few characters
> truncated from the end. Dmitry, is that intentional? The other one is
> https://groups.google.com/forum/#!msg/syzkaller-bugs/u5nq3PdPkIc/bBFjKHXPAgAJ:
>
> #syz dup: BUG: please report to dc...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
I think this happened when we started truncating kernel crash titles
to 120 columns, so it's intentional.
However, the dup command did not pass. It's hard to understand who
received what today, but this suggests that somebody altered email in
the command to dc...@vger.kernel.org:
https://groups.google.com/forum/message/raw?msg=syzkaller-bugs/GMndq4-h7BI/VIz4aBEOAwAJ
We can also mark the old one as invalid.
> Anyway, this is apparently a DCCP bug, and as I posted on the other thread it's
> easily reproducible with the following program. Gerrit, are you still the DCCP
> maintainer, or is the MAINTAINERS file outdated?
>
> #include <linux/dccp.h>
> #include <linux/in.h>
> #include <sys/socket.h>
> #include <sys/wait.h>
> #include <unistd.h>
>
> int main()
> {
> struct sockaddr_in addr = { .sin_family = AF_INET };
> socklen_t addrlen = sizeof(addr);
> int fd;
>
> while (fork())
> wait(NULL);
> fd = socket(AF_INET, SOCK_DCCP, 0);
> bind(fd, (void *)&addr, addrlen);
> getsockname(fd, (void *)&addr, &addrlen);
> listen(fd, 100);
> if (fork()) {
> fd = socket(AF_INET, SOCK_DCCP, 0);
> setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_CCID, "\x03", 1);
> connect(fd, (void *)&addr, sizeof(addr));
> } else {
> fd = accept(fd, NULL, 0);
> }
> for (int i = 0; i < 1000; i++)
> write(fd, "X", 1);
> }
>
> - Eric
^ permalink raw reply
* Re: [PATCH] isdn: eicon: fix a missing-check bug
From: Wenwen Wang @ 2018-05-09 5:30 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Armin Schindler, Karsten Keil,
open list:ISDN SUBSYSTEM, open list
In-Reply-To: <1525548766-13017-1-git-send-email-wang6495@umn.edu>
Hello
Could you please review this patch? We need a confirmation because we
are working on an approaching deadline.
Thanks!
Wenwen
On Sat, May 5, 2018 at 2:32 PM, Wenwen Wang <wang6495@umn.edu> wrote:
> In divasmain.c, the function divas_write() firstly invokes the function
> diva_xdi_open_adapter() to open the adapter that matches with the adapter
> number provided by the user, and then invokes the function diva_xdi_write()
> to perform the write operation using the matched adapter. The two functions
> diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.
>
> In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
> from the userspace pointer 'src' through the function pointer 'cp_fn',
> which eventually calls copy_from_user() to do the copy. Then, the adapter
> number 'msg.adapter' is used to find out a matched adapter from the
> 'adapter_queue'. A matched adapter will be returned if it is found.
> Otherwise, NULL is returned to indicate the failure of the verification on
> the adapter number.
>
> As mentioned above, if a matched adapter is returned, the function
> diva_xdi_write() is invoked to perform the write operation. In this
> function, the user command is copied once again from the userspace pointer
> 'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
> both of them are from the 'buf' pointer in divas_write(). Similarly, the
> copy is achieved through the function pointer 'cp_fn', which finally calls
> copy_from_user(). After the successful copy, the corresponding command
> processing handler of the matched adapter is invoked to perform the write
> operation.
>
> It is obvious that there are two copies here from userspace, one is in
> diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
> these two copies share the same source userspace pointer, i.e., the 'buf'
> pointer in divas_write(). Given that a malicious userspace process can race
> to change the content pointed by the 'buf' pointer, this can pose potential
> security issues. For example, in the first copy, the user provides a valid
> adapter number to pass the verification process and a valid adapter can be
> found. Then the user can modify the adapter number to an invalid number.
> This way, the user can bypass the verification process of the adapter
> number and inject inconsistent data.
>
> To avoid such issues, this patch adds a check after the second copy in the
> function diva_xdi_write(). If the adapter number is not equal to the one
> obtained in the first copy, (-4) will be returned to divas_write(), which
> will then return an error code -EINVAL.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
> drivers/isdn/hardware/eicon/diva.c | 6 +++++-
> drivers/isdn/hardware/eicon/divasmain.c | 3 +++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/isdn/hardware/eicon/diva.c b/drivers/isdn/hardware/eicon/diva.c
> index 944a7f3..46cbf76 100644
> --- a/drivers/isdn/hardware/eicon/diva.c
> +++ b/drivers/isdn/hardware/eicon/diva.c
> @@ -440,6 +440,7 @@ diva_xdi_write(void *adapter, void *os_handle, const void __user *src,
> int length, divas_xdi_copy_from_user_fn_t cp_fn)
> {
> diva_os_xdi_adapter_t *a = (diva_os_xdi_adapter_t *) adapter;
> + diva_xdi_um_cfg_cmd_t *p;
> void *data;
>
> if (a->xdi_mbox.status & DIVA_XDI_MBOX_BUSY) {
> @@ -461,7 +462,10 @@ diva_xdi_write(void *adapter, void *os_handle, const void __user *src,
>
> length = (*cp_fn) (os_handle, data, src, length);
> if (length > 0) {
> - if ((*(a->interface.cmd_proc))
> + p = (diva_xdi_um_cfg_cmd_t *) data;
> + if (a->controller != (int)p->adapter) {
> + length = -4;
> + } else if ((*(a->interface.cmd_proc))
> (a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
> length = -3;
> }
> diff --git a/drivers/isdn/hardware/eicon/divasmain.c b/drivers/isdn/hardware/eicon/divasmain.c
> index b9980e8..a03c658 100644
> --- a/drivers/isdn/hardware/eicon/divasmain.c
> +++ b/drivers/isdn/hardware/eicon/divasmain.c
> @@ -614,6 +614,9 @@ static ssize_t divas_write(struct file *file, const char __user *buf,
> case -3:
> ret = -ENXIO;
> break;
> + case -4:
> + ret = -EINVAL;
> + break;
> }
> DBG_TRC(("write: ret %d", ret));
> return (ret);
> --
> 2.7.4
>
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Eric Biggers @ 2018-05-09 5:40 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: dccp, Gerrit Renker, syzbot, David Miller, Gustavo A . R . Silva,
LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+b7A89ZbBUktiDjBRAtedQHMO2pZqcB4QJSM8vG8NgkGw@mail.gmail.com>
On Wed, May 09, 2018 at 07:23:41AM +0200, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> On Wed, May 9, 2018 at 7:05 AM, Eric Biggers <ebiggers3@gmail.com> wrote:
> > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
> >> git tree: upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de47800000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde7800000
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141b4be7800000
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+99858724c0ba555a12ea@syzkaller.appspotmail.com
> >>
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at
> >> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> >> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> <IRQ>
> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> >> net/dccp/ccids/lib/packet_history.c:422
> >> ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
> >> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> >> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> >> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> >> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
> >> sk_backlog_rcv include/net/sock.h:909 [inline]
> >> __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
> >> dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
> >> ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
> >> NF_HOOK include/linux/netfilter.h:288 [inline]
> >> ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
> >> dst_input include/net/dst.h:450 [inline]
> >> ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
> >> NF_HOOK include/linux/netfilter.h:288 [inline]
> >> ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
> >> __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> >> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> >> process_backlog+0x219/0x760 net/core/dev.c:5337
> >> napi_poll net/core/dev.c:5735 [inline]
> >> net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> >> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> >> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
> >> </IRQ>
> >> do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
> >> do_softirq arch/x86/include/asm/preempt.h:23 [inline]
> >> __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
> >> local_bh_enable include/linux/bottom_half.h:32 [inline]
> >> rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
> >> ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
> >> ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
> >> NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> >> ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
> >> dst_output include/net/dst.h:444 [inline]
> >> ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
> >> ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
> >> dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
> >> dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
> >> dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
> >> dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
> >> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> >> sock_sendmsg_nosec net/socket.c:629 [inline]
> >> sock_sendmsg+0xd5/0x120 net/socket.c:639
> >> ___sys_sendmsg+0x525/0x940 net/socket.c:2117
> >> __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
> >> __do_sys_sendmmsg net/socket.c:2241 [inline]
> >> __se_sys_sendmmsg net/socket.c:2238 [inline]
> >> __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
> >> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> >> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >> RIP: 0033:0x445d09
> >> RSP: 002b:00007f3c7eff5d88 EFLAGS: 00000293 ORIG_RAX: 0000000000000133
> >> RAX: ffffffffffffffda RBX: 00000000006dac40 RCX: 0000000000445d09
> >> RDX: 0000000000000001 RSI: 000000
> >>
> >>
> >> ---
> >> This bug is generated by a bot. It may contain errors.
> >> See https://goo.gl/tpsmEJ for more information about syzbot.
> >> syzbot engineers can be reached at syzkaller@googlegroups.com.
> >>
> >> syzbot will keep track of this bug report.
> >> If you forgot to add the Reported-by tag, once the fix for this bug is
> >> merged
> >> into any tree, please reply to this email with:
> >> #syz fix: exact-commit-title
> >> If you want to test a patch for this bug, please reply with:
> >> #syz test: git://repo/address.git branch
> >> and provide the patch inline or as an attachment.
> >> To mark this as a duplicate of another syzbot report, please reply with:
> >> #syz dup: exact-subject-of-another-report
> >
> > There's already a bug report with this title, this one just had a few characters
> > truncated from the end. Dmitry, is that intentional? The other one is
> > https://groups.google.com/forum/#!msg/syzkaller-bugs/u5nq3PdPkIc/bBFjKHXPAgAJ:
> >
> > #syz dup: BUG: please report to dc...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
>
> I think this happened when we started truncating kernel crash titles
> to 120 columns, so it's intentional.
> However, the dup command did not pass. It's hard to understand who
> received what today, but this suggests that somebody altered email in
> the command to dc...@vger.kernel.org:
> https://groups.google.com/forum/message/raw?msg=syzkaller-bugs/GMndq4-h7BI/VIz4aBEOAwAJ
> We can also mark the old one as invalid.
>
Ah, that was my fault -- I must have copied the bug title from the
syzkaller-bugs Google Groups page, which had mangled the email address in the
bug title. The actual title was:
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
^ permalink raw reply
* Re: linux-next: manual merge of the bpf-next tree with the s390 tree
From: Daniel Borkmann @ 2018-05-09 6:31 UTC (permalink / raw)
To: Stephen Rothwell, Networking, Martin Schwidefsky, Heiko Carstens,
David Miller
Cc: Alexei Starovoitov, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <20180509142154.73ff5772@canb.auug.org.au>
On 05/09/2018 06:21 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 8 May 2018 10:26:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the bpf-next tree got a conflict in:
>>
>> arch/s390/net/bpf_jit.S
>>
>> between commit:
>>
>> de5cb6eb514e ("s390: use expoline thunks in the BPF JIT")
>>
>> from the s390 tree and commit:
>>
>> e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")
>>
>> from the bpf-next tree.
>>
>> I fixed it up (I just removed the file as the latter does) and can
>> carry the fix as necessary. This is now fixed as far as linux-next is
>> concerned, but any non trivial conflicts should be mentioned to your
>> upstream maintainer when your tree is submitted for merging. You may
>> also want to consider cooperating with the maintainer of the conflicting
>> tree to minimise any particularly complex conflicts.
>
> This is now a conflict between the net-next and s390 trees.
Right, bpf-next merged as usual into net-next two days ago; so same
resolution applies.
^ permalink raw reply
* Re: [PATCH] isdn: eicon: fix a missing-check bug
From: Tobin C. Harding @ 2018-05-09 6:48 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Armin Schindler, Karsten Keil,
open list:ISDN SUBSYSTEM, open list
In-Reply-To: <CAAa=b7dm5zLsDHB69sNPvFkWwOjF6UV-pekEFmgrtKNod-XYSg@mail.gmail.com>
On Wed, May 09, 2018 at 12:30:18AM -0500, Wenwen Wang wrote:
> Hello
>
> Could you please review this patch? We need a confirmation because we
> are working on an approaching deadline.
I didn't know 'we' had deadlines :)
Tobin
^ permalink raw reply
* [PATCH net] tun: fix use after free for ptr_ring
From: Jason Wang @ 2018-05-09 6:59 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Jason Wang, Eric Dumazet, Cong Wang, Michael S . Tsirkin
We used to initialize ptr_ring during TUNSETIFF, this is because its
size depends on the tx_queue_len of netdevice. And we try to clean it
up when socket were detached from netdevice. A race were spotted when
trying to do uninit during a read which will lead a use after free for
pointer ring. Solving this by always initialize a zero size ptr_ring
in open() and do resizing during TUNSETIFF, and then we can safely do
cleanup during close(). With this, there's no need for the workaround
that was introduced by commit 4df0bfc79904 ("tun: fix a memory leak
for tfile->tx_array").
Reported-by: syzbot+e8b902c3c3fadf0a9dba@syzkaller.appspotmail.com
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ef33950..298cb96 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -681,15 +681,6 @@ static void tun_queue_purge(struct tun_file *tfile)
skb_queue_purge(&tfile->sk.sk_error_queue);
}
-static void tun_cleanup_tx_ring(struct tun_file *tfile)
-{
- if (tfile->tx_ring.queue) {
- ptr_ring_cleanup(&tfile->tx_ring, tun_ptr_free);
- xdp_rxq_info_unreg(&tfile->xdp_rxq);
- memset(&tfile->tx_ring, 0, sizeof(tfile->tx_ring));
- }
-}
-
static void __tun_detach(struct tun_file *tfile, bool clean)
{
struct tun_file *ntfile;
@@ -736,7 +727,8 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
tun->dev->reg_state == NETREG_REGISTERED)
unregister_netdevice(tun->dev);
}
- tun_cleanup_tx_ring(tfile);
+ if (tun)
+ xdp_rxq_info_unreg(&tfile->xdp_rxq);
sock_put(&tfile->sk);
}
}
@@ -783,14 +775,14 @@ static void tun_detach_all(struct net_device *dev)
tun_napi_del(tun, tfile);
/* Drop read queue */
tun_queue_purge(tfile);
+ xdp_rxq_info_unreg(&tfile->xdp_rxq);
sock_put(&tfile->sk);
- tun_cleanup_tx_ring(tfile);
}
list_for_each_entry_safe(tfile, tmp, &tun->disabled, next) {
tun_enable_queue(tfile);
tun_queue_purge(tfile);
+ xdp_rxq_info_unreg(&tfile->xdp_rxq);
sock_put(&tfile->sk);
- tun_cleanup_tx_ring(tfile);
}
BUG_ON(tun->numdisabled != 0);
@@ -834,7 +826,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file,
}
if (!tfile->detached &&
- ptr_ring_init(&tfile->tx_ring, dev->tx_queue_len, GFP_KERNEL)) {
+ ptr_ring_resize(&tfile->tx_ring, dev->tx_queue_len,
+ GFP_KERNEL, __skb_array_destroy_skb)) {
err = -ENOMEM;
goto out;
}
@@ -3219,6 +3212,11 @@ static int tun_chr_open(struct inode *inode, struct file * file)
&tun_proto, 0);
if (!tfile)
return -ENOMEM;
+ if (ptr_ring_init(&tfile->tx_ring, 0, GFP_KERNEL)) {
+ sk_free(&tfile->sk);
+ return -ENOMEM;
+ }
+
RCU_INIT_POINTER(tfile->tun, NULL);
tfile->flags = 0;
tfile->ifindex = 0;
@@ -3239,8 +3237,6 @@ static int tun_chr_open(struct inode *inode, struct file * file)
sock_set_flag(&tfile->sk, SOCK_ZEROCOPY);
- memset(&tfile->tx_ring, 0, sizeof(tfile->tx_ring));
-
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: Failed to clone net-next.git
From: Michal Kubecek @ 2018-05-09 7:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, songliubraving, ast, konstantin
In-Reply-To: <20180508.200442.76151477268117595.davem@davemloft.net>
On Tue, May 08, 2018 at 08:04:42PM -0400, David Miller wrote:
> From: Song Liu <songliubraving@fb.com>
> Date: Tue, 8 May 2018 17:46:23 +0000
>
> > We are seeing the following error on multiple different systems while
> > cloning net-next tree.
> >
> > $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> > Cloning into 'net-next'...
>
> Regardless of the failure, it is so _insanely_ wasteful to clone my
> trees like this.
>
> Just simply always have Linus's tree always checked out somewhere:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> Let's say you have it under src/GIT/linux as I do.
>
> Then go to src/GIT and say:
>
> git clone --reference linux/.git https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>
> This way it only downloads the objects that are unique to the net-next
> tree. Similarly for 'net':
>
> git clone --reference linux/.git https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>
> Or any other subsystem tree.
>
> Periodically "git pull --ff-only" your Linus's tree, and you'll be
> much happier in GIT land :-)
>
> As subsystem changes make their way into Linus's GIT tree, git will
> notice over time and garbage collect the dups that are in your
> subsystem GIT trees.
With reasonably recent git (>= 2.5), another option worth considering is
using worktrees:
cd /src/GIT/linux
git remote add --no-tags net-next git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
git branch --track net-next net-next/master
git worktree add ../net-next net-next
It works well for me, the only limitation to keep in mind is that you
cannot have the same branch checked out in two different worktrees at
the same time.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH net-next] tun: Do SIOCGSKNS out of rtnl_lock()
From: Jason Wang @ 2018-05-09 7:18 UTC (permalink / raw)
To: Kirill Tkhai, davem, edumazet, mst, brouer, peterpenkov96, sd,
netdev
In-Reply-To: <152579647246.21100.10461408116587658568.stgit@localhost.localdomain>
On 2018年05月09日 00:21, Kirill Tkhai wrote:
> Since net ns of tun device is assigned on the device creation,
> and it never changes, we do not need to use any lock to get it
> from alive tun.
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
> ---
> drivers/net/tun.c | 18 +++++++-----------
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index d3c04ab9752a..44d4f3d25350 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -2850,10 +2850,10 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg, int ifreq_len)
> {
> struct tun_file *tfile = file->private_data;
> + struct net *net = sock_net(&tfile->sk);
> struct tun_struct *tun;
> void __user* argp = (void __user*)arg;
> struct ifreq ifr;
> - struct net *net;
> kuid_t owner;
> kgid_t group;
> int sndbuf;
> @@ -2877,14 +2877,18 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
> */
> return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
> (unsigned int __user*)argp);
> - } else if (cmd == TUNSETQUEUE)
> + } else if (cmd == TUNSETQUEUE) {
> return tun_set_queue(file, &ifr);
> + } else if (cmd == SIOCGSKNS) {
Not for this patch, reusing socket ioctl cmd is probably not good though
they were probably not intersected (see ioctl-number.txt). We probably
need to introduce TUN specific ioctls for SIOCGSKNS and SIOCGIFHWADDR
and warn for socket ones.
Thanks
> + if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> + return -EPERM;
> + return open_related_ns(&net->ns, get_net_ns);
> + }
>
> ret = 0;
> rtnl_lock();
>
> tun = tun_get(tfile);
> - net = sock_net(&tfile->sk);
> if (cmd == TUNSETIFF) {
> ret = -EEXIST;
> if (tun)
> @@ -2914,14 +2918,6 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
> tfile->ifindex = ifindex;
> goto unlock;
> }
> - if (cmd == SIOCGSKNS) {
> - ret = -EPERM;
> - if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> - goto unlock;
> -
> - ret = open_related_ns(&net->ns, get_net_ns);
> - goto unlock;
> - }
>
> ret = -EBADFD;
> if (!tun)
>
^ permalink raw reply
* [PATCH net] nfp: flower: remove headroom from max MTU calculation
From: Jakub Kicinski @ 2018-05-09 7:18 UTC (permalink / raw)
To: davem; +Cc: oss-drivers, netdev, Pieter Jansen van Vuuren
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Since commit 29a5dcae2790 ("nfp: flower: offload phys port MTU change") we
take encapsulation headroom into account when calculating the max allowed
MTU. This is unnecessary as the max MTU advertised by firmware should have
already accounted for encap headroom.
Subtracting headroom twice brings the max MTU below what's necessary for
some deployments.
Fixes: 29a5dcae2790 ("nfp: flower: offload phys port MTU change")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
.../net/ethernet/netronome/nfp/flower/main.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c
index a997e34bcec2..84e3b9f5abb1 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.c
@@ -52,8 +52,6 @@
#define NFP_FLOWER_ALLOWED_VER 0x0001000000010000UL
-#define NFP_FLOWER_FRAME_HEADROOM 158
-
static const char *nfp_flower_extra_cap(struct nfp_app *app, struct nfp_net *nn)
{
return "FLOWER";
@@ -559,22 +557,6 @@ static void nfp_flower_clean(struct nfp_app *app)
app->priv = NULL;
}
-static int
-nfp_flower_check_mtu(struct nfp_app *app, struct net_device *netdev,
- int new_mtu)
-{
- /* The flower fw reserves NFP_FLOWER_FRAME_HEADROOM bytes of the
- * supported max MTU to allow for appending tunnel headers. To prevent
- * unexpected behaviour this needs to be accounted for.
- */
- if (new_mtu > netdev->max_mtu - NFP_FLOWER_FRAME_HEADROOM) {
- nfp_err(app->cpp, "New MTU (%d) is not valid\n", new_mtu);
- return -EINVAL;
- }
-
- return 0;
-}
-
static bool nfp_flower_check_ack(struct nfp_flower_priv *app_priv)
{
bool ret;
@@ -656,7 +638,6 @@ const struct nfp_app_type app_flower = {
.init = nfp_flower_init,
.clean = nfp_flower_clean,
- .check_mtu = nfp_flower_check_mtu,
.repr_change_mtu = nfp_flower_repr_change_mtu,
.vnic_alloc = nfp_flower_vnic_alloc,
--
2.17.0
^ permalink raw reply related
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