* 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
* Re: pull-request: ieee802154 2018-05-08
From: Stefan Schmidt @ 2018-05-09 7:31 UTC (permalink / raw)
To: David Miller; +Cc: s.schmidt, linux-wpan, alex.aring, netdev
In-Reply-To: <20180508.200638.1908252284342544792.davem@davemloft.net>
Hello.
On 05/09/2018 02:06 AM, David Miller wrote:
> From: Stefan Schmidt <stefan@osg.samsung.com>
> Date: Tue, 8 May 2018 21:55:37 +0200
>
>> On 05/08/2018 04:18 PM, David Miller wrote:
>>> Please submit the -stable fix directly, you can feel free to CC: me.
>> Will do when the patch hits Linus git tree.
>>
>> I have a quick question on the process here. From the netdev-faq document
>> I was under the impression all stable patches under net/ and drivers/net
>> should be brought up to you and would be handled by you.
>>
>> Does this apply to the core part of net (I fully understand that ieee802154
>> is rather a niche) or is there some other reason for this exception?
>>
>> Both processes (the normal stable one as well as the slightly different one
>> for net/) would be fine to go with for me. Just need to know which one I
>> should use for future stable patches. :-)
>>
>> regards
>> Stefan Schmidt
> Generally wireless and ipsec have been submitting them directly,
> sometimes the Intel ethernet guys do too.
>
> Sometimes this makes things easier for me, and I'll ask you to submit
> things directly when that is the case like right now.
Thanks for taking the time to explain it. I will go ahead and handle
the stable patches for ieee802154 directly from now on. If you want
to have this changed again just let me know.
regards
Stefan Schmidt
^ permalink raw reply
* Re: KASAN: use-after-free Read in __dev_queue_xmit
From: Eric Biggers @ 2018-05-09 7:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, syzbot, alexander.deucher, Andrey Konovalov,
Anoob Soman, chris, David Miller, elena.reshetova,
Greg Kroah-Hartman, Kees Cook, LKML, Mike Maloney, mchehab,
netdev, rami.rosen, Sowmini Varadhan, syzkaller-bugs,
Willem de Bruijn
In-Reply-To: <1515048794.131759.4.camel@gmail.com>
On Wed, Jan 03, 2018 at 10:53:14PM -0800, Eric Dumazet wrote:
> On Wed, 2018-01-03 at 21:13 -0800, Eric Dumazet wrote:
> > Note: all commands must start from beginning of the line in the email body.
> >
> > I guess skb_probe_transport_header() should be hardened to reject malicious
> > packets given by user space, instead of being gentle.
>
> Although bug triggered for this particular repro is in flow dissector
> :/
>
> I will test :
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 15ce300637650e17fcab7e378b20fe7972686d46..544bddf08e13c7f6e47aadc737244c9ba5af56b2 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -976,8 +976,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> out_good:
> ret = true;
>
> - key_control->thoff = (u16)nhoff;
> out:
> + key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> key_basic->n_proto = proto;
> key_basic->ip_proto = ip_proto;
>
> @@ -985,7 +985,6 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>
> out_bad:
> ret = false;
> - key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> goto out;
> }
> EXPORT_SYMBOL(__skb_flow_dissect);
Fix for this was commit d0c081b49137cd:
#syz fix: flow_dissector: properly cap thoff field
But a crash with the same signature is still occurring, so it should eventually
get reported again. C reproducer is here, it works on Linus' tree (commit
036db8bd963): https://syzkaller.appspot.com/text?tag=ReproC&x=105b1ae7800000
- Eric
^ permalink raw reply
* Re: [bpf-next v2 8/9] bpf: Provide helper to do forwarding lookups in kernel FIB table
From: Daniel Borkmann @ 2018-05-09 8:15 UTC (permalink / raw)
To: David Ahern, netdev, borkmann, ast
Cc: davem, shm, roopa, brouer, toke, john.fastabend
In-Reply-To: <20180504025432.23451-9-dsahern@gmail.com>
On 05/04/2018 04:54 AM, David Ahern wrote:
> Provide a helper for doing a FIB and neighbor lookup in the kernel
> tables from an XDP program. The helper provides a fastpath for forwarding
> packets. If the packet is a local delivery or for any reason is not a
> simple lookup and forward, the packet continues up the stack.
>
> If it is to be forwarded, the forwarding can be done directly if the
> neighbor is already known. If the neighbor does not exist, the first
> few packets go up the stack for neighbor resolution. Once resolved, the
> xdp program provides the fast path.
>
> On successful lookup the nexthop dmac, current device smac and egress
> device index are returned.
>
> The API supports IPv4, IPv6 and MPLS protocols, but only IPv4 and IPv6
> are implemented in this patch. The API includes layer 4 parameters if
> the XDP program chooses to do deep packet inspection to allow compare
> against ACLs implemented as FIB rules.
>
> Header rewrite is left to the XDP program.
>
> The lookup takes 2 flags:
> - BPF_FIB_LOOKUP_DIRECT to do a lookup that bypasses FIB rules and goes
> straight to the table associated with the device (expert setting for
> those looking to maximize throughput)
>
> - BPF_FIB_LOOKUP_OUTPUT to do a lookup from the egress perspective.
> Default is an ingress lookup.
>
> Initial performance numbers collected by Jesper, forwarded packets/sec:
>
> Full stack XDP FIB lookup XDP Direct lookup
> IPv4 1,947,969 7,074,156 7,415,333
> IPv6 1,728,000 6,165,504 7,262,720
>
> These number are single CPU core forwarding on a Broadwell
> E5-1650 v4 @ 3.60GHz.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Ohh well, this is causing allmodconfig build warnings (e.g. on x86) as reported today:
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)
Lets get a clean, proper version of the whole series into bpf-next. I've dropped it
from there right now and waiting for your v3 respin to apply with the above fixed.
Thank you.
^ permalink raw reply
* [PATCH v2] hv_netvsc: Fix net device attach on older Windows hosts
From: Mohammed Gamal @ 2018-05-09 8:17 UTC (permalink / raw)
To: netdev, sthemmin; +Cc: Mohammed Gamal, haiyangz, linux-kernel, devel, vkuznets
On older windows hosts the net_device instance is returned to
the caller of rndis_filter_device_add() without having the presence
bit set first. This would cause any subsequent calls to network device
operations (e.g. MTU change, channel change) to fail after the device
is detached once, returning -ENODEV.
Instead of returning the device instabce, we take the exit path where
we call netif_device_attach()
Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/rndis_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 6b127be..e7ca5b5 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1288,7 +1288,7 @@ struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
rndis_device->link_state ? "down" : "up");
if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
- return net_device;
+ goto out;
rndis_filter_query_link_speed(rndis_device, net_device);
--
1.8.3.1
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Anders Roxell @ 2018-05-09 8:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <20180509141908.7b07df43@canb.auug.org.au>
On 9 May 2018 at 06:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 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
in_netns.sh shouldn't be in the above list, its already in the
TEST_PROGS_EXTENDED below.
Cheers,
Anders
> + 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
>
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: fix added_by_user switchdev notification
From: Petr Machata @ 2018-05-09 8:54 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, jiri, idosch, ivecera, davem,
stephen, andrew, f.fainelli, nikolay, bridge
In-Reply-To: <20180509030312.29548-1-vivien.didelot@savoirfairelinux.com>
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> @petr I expect the same issue with Rocker, but I haven't tested it.
Yeah, pretty sure. Such an obvious bug, sorry about that :-/
I'll send a rocker patch later today.
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH net-next] tun: Do SIOCGSKNS out of rtnl_lock()
From: Kirill Tkhai @ 2018-05-09 9:00 UTC (permalink / raw)
To: Jason Wang, davem, edumazet, mst, brouer, peterpenkov96, sd,
netdev
In-Reply-To: <06a89506-2d3c-a0dd-3ac2-2c517683517e@redhat.com>
Hi, Jason,
On 09.05.2018 10:18, Jason Wang wrote:
>
>
> 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.
The most of socket ioctl cmds use 0x8900 type:
#define SOCK_IOC_TYPE 0x89
while tun cmd is 5400 ('T'). They should not intersect.
The only exceptions are
#define SIOCINQ FIONREAD
#define SIOCOUTQ TIOCOUTQ
#define TIOCOUTQ 0x5411
#define FIONREAD 0x541B
But they can't intersect even with exceptions, since tun nr starts from 200:
#define TUNSETNOCSUM _IOW('T', 200, int)
and 200 > 0x1b (==27).
I implemented SIOCGSKNS cmd in the same style as older socket cmds were used.
I'm not sure, we can remove existing SIOCGIFHWADDR, since they are already used.
If we add a warn, which time will we able to remove them? Some old software may
use it, and in case of the program isn't developed any more, nobody can fix this
warnings, even if he/she sees them..
Kirill
>
>> + 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
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