<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net, branch v4.14.154</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>ipvs: move old_secure_tcp into struct netns_ipvs</title>
<updated>2019-11-12T18:18:38+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2019-10-23T16:53:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3a0018ef9628b70fdb6d5a30c8d8e17f6ac1f9e2'/>
<id>3a0018ef9628b70fdb6d5a30c8d8e17f6ac1f9e2</id>
<content type='text'>
[ Upstream commit c24b75e0f9239e78105f81c5f03a751641eb07ef ]

syzbot reported the following issue :

BUG: KCSAN: data-race in update_defense_level / update_defense_level

read to 0xffffffff861a6260 of 4 bytes by task 3006 on cpu 1:
 update_defense_level+0x621/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:177
 defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
 worker_thread+0xa0/0x800 kernel/workqueue.c:2415
 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352

write to 0xffffffff861a6260 of 4 bytes by task 7333 on cpu 0:
 update_defense_level+0xa62/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:205
 defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
 worker_thread+0xa0/0x800 kernel/workqueue.c:2415
 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 7333 Comm: kworker/0:5 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events defense_work_handler

Indeed, old_secure_tcp is currently a static variable, while it
needs to be a per netns variable.

Fixes: a0840e2e165a ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c24b75e0f9239e78105f81c5f03a751641eb07ef ]

syzbot reported the following issue :

BUG: KCSAN: data-race in update_defense_level / update_defense_level

read to 0xffffffff861a6260 of 4 bytes by task 3006 on cpu 1:
 update_defense_level+0x621/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:177
 defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
 worker_thread+0xa0/0x800 kernel/workqueue.c:2415
 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352

write to 0xffffffff861a6260 of 4 bytes by task 7333 on cpu 0:
 update_defense_level+0xa62/0xb30 net/netfilter/ipvs/ip_vs_ctl.c:205
 defense_work_handler+0x3d/0xd0 net/netfilter/ipvs/ip_vs_ctl.c:225
 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
 worker_thread+0xa0/0x800 kernel/workqueue.c:2415
 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 7333 Comm: kworker/0:5 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events defense_work_handler

Indeed, old_secure_tcp is currently a static variable, while it
needs to be a per netns variable.

Fixes: a0840e2e165a ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipvs: don't ignore errors in case refcounting ip_vs module fails</title>
<updated>2019-11-12T18:18:38+00:00</updated>
<author>
<name>Davide Caratti</name>
<email>dcaratti@redhat.com</email>
</author>
<published>2019-10-19T15:34:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=78ec9c409e932b0a1a198cd8e20a3a66e346d72d'/>
<id>78ec9c409e932b0a1a198cd8e20a3a66e346d72d</id>
<content type='text'>
[ Upstream commit 62931f59ce9cbabb934a431f48f2f1f441c605ac ]

if the IPVS module is removed while the sync daemon is starting, there is
a small gap where try_module_get() might fail getting the refcount inside
ip_vs_use_count_inc(). Then, the refcounts of IPVS module are unbalanced,
and the subsequent call to stop_sync_thread() causes the following splat:

 WARNING: CPU: 0 PID: 4013 at kernel/module.c:1146 module_put.part.44+0x15b/0x290
  Modules linked in: ip_vs(-) nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 veth ip6table_filter ip6_tables iptable_filter binfmt_misc intel_rapl_msr intel_rapl_common crct10dif_pclmul crc32_pclmul ext4 mbcache jbd2 ghash_clmulni_intel snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_nhlt snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper joydev pcspkr snd_timer virtio_balloon snd soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net net_failover virtio_blk failover virtio_console qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ata_piix ttm crc32c_intel serio_raw drm virtio_pci libata virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: nf_defrag_ipv6]
  CPU: 0 PID: 4013 Comm: modprobe Tainted: G        W         5.4.0-rc1.upstream+ #741
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  RIP: 0010:module_put.part.44+0x15b/0x290
  Code: 04 25 28 00 00 00 0f 85 18 01 00 00 48 83 c4 68 5b 5d 41 5c 41 5d 41 5e 41 5f c3 89 44 24 28 83 e8 01 89 c5 0f 89 57 ff ff ff &lt;0f&gt; 0b e9 78 ff ff ff 65 8b 1d 67 83 26 4a 89 db be 08 00 00 00 48
  RSP: 0018:ffff888050607c78 EFLAGS: 00010297
  RAX: 0000000000000003 RBX: ffffffffc1420590 RCX: ffffffffb5db0ef9
  RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffc1420590
  RBP: 00000000ffffffff R08: fffffbfff82840b3 R09: fffffbfff82840b3
  R10: 0000000000000001 R11: fffffbfff82840b2 R12: 1ffff1100a0c0f90
  R13: ffffffffc1420200 R14: ffff88804f533300 R15: ffff88804f533ca0
  FS:  00007f8ea9720740(0000) GS:ffff888053800000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f3245abe000 CR3: 000000004c28a006 CR4: 00000000001606f0
  Call Trace:
   stop_sync_thread+0x3a3/0x7c0 [ip_vs]
   ip_vs_sync_net_cleanup+0x13/0x50 [ip_vs]
   ops_exit_list.isra.5+0x94/0x140
   unregister_pernet_operations+0x29d/0x460
   unregister_pernet_device+0x26/0x60
   ip_vs_cleanup+0x11/0x38 [ip_vs]
   __x64_sys_delete_module+0x2d5/0x400
   do_syscall_64+0xa5/0x4e0
   entry_SYSCALL_64_after_hwframe+0x49/0xbe
  RIP: 0033:0x7f8ea8bf0db7
  Code: 73 01 c3 48 8b 0d b9 80 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 89 80 2c 00 f7 d8 64 89 01 48
  RSP: 002b:00007ffcd38d2fe8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
  RAX: ffffffffffffffda RBX: 0000000002436240 RCX: 00007f8ea8bf0db7
  RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00000000024362a8
  RBP: 0000000000000000 R08: 00007f8ea8eba060 R09: 00007f8ea8c658a0
  R10: 00007ffcd38d2a60 R11: 0000000000000206 R12: 0000000000000000
  R13: 0000000000000001 R14: 00000000024362a8 R15: 0000000000000000
  irq event stamp: 4538
  hardirqs last  enabled at (4537): [&lt;ffffffffb6193dde&gt;] quarantine_put+0x9e/0x170
  hardirqs last disabled at (4538): [&lt;ffffffffb5a0556a&gt;] trace_hardirqs_off_thunk+0x1a/0x20
  softirqs last  enabled at (4522): [&lt;ffffffffb6f8ebe9&gt;] sk_common_release+0x169/0x2d0
  softirqs last disabled at (4520): [&lt;ffffffffb6f8eb3e&gt;] sk_common_release+0xbe/0x2d0

Check the return value of ip_vs_use_count_inc() and let its caller return
proper error. Inside do_ip_vs_set_ctl() the module is already refcounted,
we don't need refcount/derefcount there. Finally, in register_ip_vs_app()
and start_sync_thread(), take the module refcount earlier and ensure it's
released in the error path.

Change since v1:
 - better return values in case of failure of ip_vs_use_count_inc(),
   thanks to Julian Anastasov
 - no need to increase/decrease the module refcount in ip_vs_set_ctl(),
   thanks to Julian Anastasov

Signed-off-by: Davide Caratti &lt;dcaratti@redhat.com&gt;
Signed-off-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 62931f59ce9cbabb934a431f48f2f1f441c605ac ]

if the IPVS module is removed while the sync daemon is starting, there is
a small gap where try_module_get() might fail getting the refcount inside
ip_vs_use_count_inc(). Then, the refcounts of IPVS module are unbalanced,
and the subsequent call to stop_sync_thread() causes the following splat:

 WARNING: CPU: 0 PID: 4013 at kernel/module.c:1146 module_put.part.44+0x15b/0x290
  Modules linked in: ip_vs(-) nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 veth ip6table_filter ip6_tables iptable_filter binfmt_misc intel_rapl_msr intel_rapl_common crct10dif_pclmul crc32_pclmul ext4 mbcache jbd2 ghash_clmulni_intel snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_nhlt snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper joydev pcspkr snd_timer virtio_balloon snd soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net net_failover virtio_blk failover virtio_console qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ata_piix ttm crc32c_intel serio_raw drm virtio_pci libata virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: nf_defrag_ipv6]
  CPU: 0 PID: 4013 Comm: modprobe Tainted: G        W         5.4.0-rc1.upstream+ #741
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  RIP: 0010:module_put.part.44+0x15b/0x290
  Code: 04 25 28 00 00 00 0f 85 18 01 00 00 48 83 c4 68 5b 5d 41 5c 41 5d 41 5e 41 5f c3 89 44 24 28 83 e8 01 89 c5 0f 89 57 ff ff ff &lt;0f&gt; 0b e9 78 ff ff ff 65 8b 1d 67 83 26 4a 89 db be 08 00 00 00 48
  RSP: 0018:ffff888050607c78 EFLAGS: 00010297
  RAX: 0000000000000003 RBX: ffffffffc1420590 RCX: ffffffffb5db0ef9
  RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffc1420590
  RBP: 00000000ffffffff R08: fffffbfff82840b3 R09: fffffbfff82840b3
  R10: 0000000000000001 R11: fffffbfff82840b2 R12: 1ffff1100a0c0f90
  R13: ffffffffc1420200 R14: ffff88804f533300 R15: ffff88804f533ca0
  FS:  00007f8ea9720740(0000) GS:ffff888053800000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f3245abe000 CR3: 000000004c28a006 CR4: 00000000001606f0
  Call Trace:
   stop_sync_thread+0x3a3/0x7c0 [ip_vs]
   ip_vs_sync_net_cleanup+0x13/0x50 [ip_vs]
   ops_exit_list.isra.5+0x94/0x140
   unregister_pernet_operations+0x29d/0x460
   unregister_pernet_device+0x26/0x60
   ip_vs_cleanup+0x11/0x38 [ip_vs]
   __x64_sys_delete_module+0x2d5/0x400
   do_syscall_64+0xa5/0x4e0
   entry_SYSCALL_64_after_hwframe+0x49/0xbe
  RIP: 0033:0x7f8ea8bf0db7
  Code: 73 01 c3 48 8b 0d b9 80 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 89 80 2c 00 f7 d8 64 89 01 48
  RSP: 002b:00007ffcd38d2fe8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
  RAX: ffffffffffffffda RBX: 0000000002436240 RCX: 00007f8ea8bf0db7
  RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00000000024362a8
  RBP: 0000000000000000 R08: 00007f8ea8eba060 R09: 00007f8ea8c658a0
  R10: 00007ffcd38d2a60 R11: 0000000000000206 R12: 0000000000000000
  R13: 0000000000000001 R14: 00000000024362a8 R15: 0000000000000000
  irq event stamp: 4538
  hardirqs last  enabled at (4537): [&lt;ffffffffb6193dde&gt;] quarantine_put+0x9e/0x170
  hardirqs last disabled at (4538): [&lt;ffffffffb5a0556a&gt;] trace_hardirqs_off_thunk+0x1a/0x20
  softirqs last  enabled at (4522): [&lt;ffffffffb6f8ebe9&gt;] sk_common_release+0x169/0x2d0
  softirqs last disabled at (4520): [&lt;ffffffffb6f8eb3e&gt;] sk_common_release+0xbe/0x2d0

Check the return value of ip_vs_use_count_inc() and let its caller return
proper error. Inside do_ip_vs_set_ctl() the module is already refcounted,
we don't need refcount/derefcount there. Finally, in register_ip_vs_app()
and start_sync_thread(), take the module refcount earlier and ensure it's
released in the error path.

Change since v1:
 - better return values in case of failure of ip_vs_use_count_inc(),
   thanks to Julian Anastasov
 - no need to increase/decrease the module refcount in ip_vs_set_ctl(),
   thanks to Julian Anastasov

Signed-off-by: Davide Caratti &lt;dcaratti@redhat.com&gt;
Signed-off-by: Julian Anastasov &lt;ja@ssi.bg&gt;
Signed-off-by: Simon Horman &lt;horms@verge.net.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: openvswitch: free vport unless register_netdevice() succeeds</title>
<updated>2019-11-12T18:18:37+00:00</updated>
<author>
<name>Hillf Danton</name>
<email>hdanton@sina.com</email>
</author>
<published>2019-10-21T10:01:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=107e5b0b9ed11d99e409e4a3e120237710c39e95'/>
<id>107e5b0b9ed11d99e409e4a3e120237710c39e95</id>
<content type='text'>
[ Upstream commit 9464cc37f3671ee69cb1c00662b5e1f113a96b23 ]

syzbot found the following crash on:

HEAD commit:    1e78030e Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148d3d1a600000
kernel config:  https://syzkaller.appspot.com/x/.config?x=30cef20daf3e9977
dashboard link: https://syzkaller.appspot.com/bug?extid=13210896153522fe1ee5
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=136aa8c4600000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=109ba792600000

=====================================================================
BUG: memory leak
unreferenced object 0xffff8881207e4100 (size 128):
   comm "syz-executor032", pid 7014, jiffies 4294944027 (age 13.830s)
   hex dump (first 32 bytes):
     00 70 16 18 81 88 ff ff 80 af 8c 22 81 88 ff ff  .p........."....
     00 b6 23 17 81 88 ff ff 00 00 00 00 00 00 00 00  ..#.............
   backtrace:
     [&lt;000000000eb78212&gt;] kmemleak_alloc_recursive  include/linux/kmemleak.h:43 [inline]
     [&lt;000000000eb78212&gt;] slab_post_alloc_hook mm/slab.h:522 [inline]
     [&lt;000000000eb78212&gt;] slab_alloc mm/slab.c:3319 [inline]
     [&lt;000000000eb78212&gt;] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
     [&lt;00000000006ea6c6&gt;] kmalloc include/linux/slab.h:552 [inline]
     [&lt;00000000006ea6c6&gt;] kzalloc include/linux/slab.h:748 [inline]
     [&lt;00000000006ea6c6&gt;] ovs_vport_alloc+0x37/0xf0  net/openvswitch/vport.c:130
     [&lt;00000000f9a04a7d&gt;] internal_dev_create+0x24/0x1d0  net/openvswitch/vport-internal_dev.c:164
     [&lt;0000000056ee7c13&gt;] ovs_vport_add+0x81/0x190  net/openvswitch/vport.c:199
     [&lt;000000005434efc7&gt;] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
     [&lt;00000000b7b253f1&gt;] ovs_dp_cmd_new+0x22f/0x410  net/openvswitch/datapath.c:1614
     [&lt;00000000e0988518&gt;] genl_family_rcv_msg+0x2ab/0x5b0  net/netlink/genetlink.c:629
     [&lt;00000000d0cc9347&gt;] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
     [&lt;000000006694b647&gt;] netlink_rcv_skb+0x61/0x170  net/netlink/af_netlink.c:2477
     [&lt;0000000088381f37&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
     [&lt;00000000dad42a47&gt;] netlink_unicast_kernel  net/netlink/af_netlink.c:1302 [inline]
     [&lt;00000000dad42a47&gt;] netlink_unicast+0x1ec/0x2d0  net/netlink/af_netlink.c:1328
     [&lt;0000000067e6b079&gt;] netlink_sendmsg+0x270/0x480  net/netlink/af_netlink.c:1917
     [&lt;00000000aab08a47&gt;] sock_sendmsg_nosec net/socket.c:637 [inline]
     [&lt;00000000aab08a47&gt;] sock_sendmsg+0x54/0x70 net/socket.c:657
     [&lt;000000004cb7c11d&gt;] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
     [&lt;00000000c4901c63&gt;] __sys_sendmsg+0x80/0xf0 net/socket.c:2356
     [&lt;00000000c10abb2d&gt;] __do_sys_sendmsg net/socket.c:2365 [inline]
     [&lt;00000000c10abb2d&gt;] __se_sys_sendmsg net/socket.c:2363 [inline]
     [&lt;00000000c10abb2d&gt;] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2363

BUG: memory leak
unreferenced object 0xffff88811723b600 (size 64):
   comm "syz-executor032", pid 7014, jiffies 4294944027 (age 13.830s)
   hex dump (first 32 bytes):
     01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
     00 00 00 00 00 00 00 00 02 00 00 00 05 35 82 c1  .............5..
   backtrace:
     [&lt;00000000352f46d8&gt;] kmemleak_alloc_recursive  include/linux/kmemleak.h:43 [inline]
     [&lt;00000000352f46d8&gt;] slab_post_alloc_hook mm/slab.h:522 [inline]
     [&lt;00000000352f46d8&gt;] slab_alloc mm/slab.c:3319 [inline]
     [&lt;00000000352f46d8&gt;] __do_kmalloc mm/slab.c:3653 [inline]
     [&lt;00000000352f46d8&gt;] __kmalloc+0x169/0x300 mm/slab.c:3664
     [&lt;000000008e48f3d1&gt;] kmalloc include/linux/slab.h:557 [inline]
     [&lt;000000008e48f3d1&gt;] ovs_vport_set_upcall_portids+0x54/0xd0  net/openvswitch/vport.c:343
     [&lt;00000000541e4f4a&gt;] ovs_vport_alloc+0x7f/0xf0  net/openvswitch/vport.c:139
     [&lt;00000000f9a04a7d&gt;] internal_dev_create+0x24/0x1d0  net/openvswitch/vport-internal_dev.c:164
     [&lt;0000000056ee7c13&gt;] ovs_vport_add+0x81/0x190  net/openvswitch/vport.c:199
     [&lt;000000005434efc7&gt;] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
     [&lt;00000000b7b253f1&gt;] ovs_dp_cmd_new+0x22f/0x410  net/openvswitch/datapath.c:1614
     [&lt;00000000e0988518&gt;] genl_family_rcv_msg+0x2ab/0x5b0  net/netlink/genetlink.c:629
     [&lt;00000000d0cc9347&gt;] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
     [&lt;000000006694b647&gt;] netlink_rcv_skb+0x61/0x170  net/netlink/af_netlink.c:2477
     [&lt;0000000088381f37&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
     [&lt;00000000dad42a47&gt;] netlink_unicast_kernel  net/netlink/af_netlink.c:1302 [inline]
     [&lt;00000000dad42a47&gt;] netlink_unicast+0x1ec/0x2d0  net/netlink/af_netlink.c:1328
     [&lt;0000000067e6b079&gt;] netlink_sendmsg+0x270/0x480  net/netlink/af_netlink.c:1917
     [&lt;00000000aab08a47&gt;] sock_sendmsg_nosec net/socket.c:637 [inline]
     [&lt;00000000aab08a47&gt;] sock_sendmsg+0x54/0x70 net/socket.c:657
     [&lt;000000004cb7c11d&gt;] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
     [&lt;00000000c4901c63&gt;] __sys_sendmsg+0x80/0xf0 net/socket.c:2356

BUG: memory leak
unreferenced object 0xffff8881228ca500 (size 128):
   comm "syz-executor032", pid 7015, jiffies 4294944622 (age 7.880s)
   hex dump (first 32 bytes):
     00 f0 27 18 81 88 ff ff 80 ac 8c 22 81 88 ff ff  ..'........"....
     40 b7 23 17 81 88 ff ff 00 00 00 00 00 00 00 00  @.#.............
   backtrace:
     [&lt;000000000eb78212&gt;] kmemleak_alloc_recursive  include/linux/kmemleak.h:43 [inline]
     [&lt;000000000eb78212&gt;] slab_post_alloc_hook mm/slab.h:522 [inline]
     [&lt;000000000eb78212&gt;] slab_alloc mm/slab.c:3319 [inline]
     [&lt;000000000eb78212&gt;] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
     [&lt;00000000006ea6c6&gt;] kmalloc include/linux/slab.h:552 [inline]
     [&lt;00000000006ea6c6&gt;] kzalloc include/linux/slab.h:748 [inline]
     [&lt;00000000006ea6c6&gt;] ovs_vport_alloc+0x37/0xf0  net/openvswitch/vport.c:130
     [&lt;00000000f9a04a7d&gt;] internal_dev_create+0x24/0x1d0  net/openvswitch/vport-internal_dev.c:164
     [&lt;0000000056ee7c13&gt;] ovs_vport_add+0x81/0x190  net/openvswitch/vport.c:199
     [&lt;000000005434efc7&gt;] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
     [&lt;00000000b7b253f1&gt;] ovs_dp_cmd_new+0x22f/0x410  net/openvswitch/datapath.c:1614
     [&lt;00000000e0988518&gt;] genl_family_rcv_msg+0x2ab/0x5b0  net/netlink/genetlink.c:629
     [&lt;00000000d0cc9347&gt;] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
     [&lt;000000006694b647&gt;] netlink_rcv_skb+0x61/0x170  net/netlink/af_netlink.c:2477
     [&lt;0000000088381f37&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
     [&lt;00000000dad42a47&gt;] netlink_unicast_kernel  net/netlink/af_netlink.c:1302 [inline]
     [&lt;00000000dad42a47&gt;] netlink_unicast+0x1ec/0x2d0  net/netlink/af_netlink.c:1328
     [&lt;0000000067e6b079&gt;] netlink_sendmsg+0x270/0x480  net/netlink/af_netlink.c:1917
     [&lt;00000000aab08a47&gt;] sock_sendmsg_nosec net/socket.c:637 [inline]
     [&lt;00000000aab08a47&gt;] sock_sendmsg+0x54/0x70 net/socket.c:657
     [&lt;000000004cb7c11d&gt;] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
     [&lt;00000000c4901c63&gt;] __sys_sendmsg+0x80/0xf0 net/socket.c:2356
     [&lt;00000000c10abb2d&gt;] __do_sys_sendmsg net/socket.c:2365 [inline]
     [&lt;00000000c10abb2d&gt;] __se_sys_sendmsg net/socket.c:2363 [inline]
     [&lt;00000000c10abb2d&gt;] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2363
=====================================================================

The function in net core, register_netdevice(), may fail with vport's
destruction callback either invoked or not. After commit 309b66970ee2
("net: openvswitch: do not free vport if register_netdevice() is failed."),
the duty to destroy vport is offloaded from the driver OTOH, which ends
up in the memory leak reported.

It is fixed by releasing vport unless device is registered successfully.
To do that, the callback assignment is defered until device is registered.

Reported-by: syzbot+13210896153522fe1ee5@syzkaller.appspotmail.com
Fixes: 309b66970ee2 ("net: openvswitch: do not free vport if register_netdevice() is failed.")
Cc: Taehee Yoo &lt;ap420073@gmail.com&gt;
Cc: Greg Rose &lt;gvrose8192@gmail.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Cc: Ying Xue &lt;ying.xue@windriver.com&gt;
Cc: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Signed-off-by: Hillf Danton &lt;hdanton@sina.com&gt;
Acked-by: Pravin B Shelar &lt;pshelar@ovn.org&gt;
[sbrivio: this was sent to dev@openvswitch.org and never made its way
 to netdev -- resending original patch]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
Reviewed-by: Greg Rose &lt;gvrose8192@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;jakub.kicinski@netronome.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9464cc37f3671ee69cb1c00662b5e1f113a96b23 ]

syzbot found the following crash on:

HEAD commit:    1e78030e Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148d3d1a600000
kernel config:  https://syzkaller.appspot.com/x/.config?x=30cef20daf3e9977
dashboard link: https://syzkaller.appspot.com/bug?extid=13210896153522fe1ee5
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=136aa8c4600000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=109ba792600000

=====================================================================
BUG: memory leak
unreferenced object 0xffff8881207e4100 (size 128):
   comm "syz-executor032", pid 7014, jiffies 4294944027 (age 13.830s)
   hex dump (first 32 bytes):
     00 70 16 18 81 88 ff ff 80 af 8c 22 81 88 ff ff  .p........."....
     00 b6 23 17 81 88 ff ff 00 00 00 00 00 00 00 00  ..#.............
   backtrace:
     [&lt;000000000eb78212&gt;] kmemleak_alloc_recursive  include/linux/kmemleak.h:43 [inline]
     [&lt;000000000eb78212&gt;] slab_post_alloc_hook mm/slab.h:522 [inline]
     [&lt;000000000eb78212&gt;] slab_alloc mm/slab.c:3319 [inline]
     [&lt;000000000eb78212&gt;] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
     [&lt;00000000006ea6c6&gt;] kmalloc include/linux/slab.h:552 [inline]
     [&lt;00000000006ea6c6&gt;] kzalloc include/linux/slab.h:748 [inline]
     [&lt;00000000006ea6c6&gt;] ovs_vport_alloc+0x37/0xf0  net/openvswitch/vport.c:130
     [&lt;00000000f9a04a7d&gt;] internal_dev_create+0x24/0x1d0  net/openvswitch/vport-internal_dev.c:164
     [&lt;0000000056ee7c13&gt;] ovs_vport_add+0x81/0x190  net/openvswitch/vport.c:199
     [&lt;000000005434efc7&gt;] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
     [&lt;00000000b7b253f1&gt;] ovs_dp_cmd_new+0x22f/0x410  net/openvswitch/datapath.c:1614
     [&lt;00000000e0988518&gt;] genl_family_rcv_msg+0x2ab/0x5b0  net/netlink/genetlink.c:629
     [&lt;00000000d0cc9347&gt;] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
     [&lt;000000006694b647&gt;] netlink_rcv_skb+0x61/0x170  net/netlink/af_netlink.c:2477
     [&lt;0000000088381f37&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
     [&lt;00000000dad42a47&gt;] netlink_unicast_kernel  net/netlink/af_netlink.c:1302 [inline]
     [&lt;00000000dad42a47&gt;] netlink_unicast+0x1ec/0x2d0  net/netlink/af_netlink.c:1328
     [&lt;0000000067e6b079&gt;] netlink_sendmsg+0x270/0x480  net/netlink/af_netlink.c:1917
     [&lt;00000000aab08a47&gt;] sock_sendmsg_nosec net/socket.c:637 [inline]
     [&lt;00000000aab08a47&gt;] sock_sendmsg+0x54/0x70 net/socket.c:657
     [&lt;000000004cb7c11d&gt;] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
     [&lt;00000000c4901c63&gt;] __sys_sendmsg+0x80/0xf0 net/socket.c:2356
     [&lt;00000000c10abb2d&gt;] __do_sys_sendmsg net/socket.c:2365 [inline]
     [&lt;00000000c10abb2d&gt;] __se_sys_sendmsg net/socket.c:2363 [inline]
     [&lt;00000000c10abb2d&gt;] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2363

BUG: memory leak
unreferenced object 0xffff88811723b600 (size 64):
   comm "syz-executor032", pid 7014, jiffies 4294944027 (age 13.830s)
   hex dump (first 32 bytes):
     01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
     00 00 00 00 00 00 00 00 02 00 00 00 05 35 82 c1  .............5..
   backtrace:
     [&lt;00000000352f46d8&gt;] kmemleak_alloc_recursive  include/linux/kmemleak.h:43 [inline]
     [&lt;00000000352f46d8&gt;] slab_post_alloc_hook mm/slab.h:522 [inline]
     [&lt;00000000352f46d8&gt;] slab_alloc mm/slab.c:3319 [inline]
     [&lt;00000000352f46d8&gt;] __do_kmalloc mm/slab.c:3653 [inline]
     [&lt;00000000352f46d8&gt;] __kmalloc+0x169/0x300 mm/slab.c:3664
     [&lt;000000008e48f3d1&gt;] kmalloc include/linux/slab.h:557 [inline]
     [&lt;000000008e48f3d1&gt;] ovs_vport_set_upcall_portids+0x54/0xd0  net/openvswitch/vport.c:343
     [&lt;00000000541e4f4a&gt;] ovs_vport_alloc+0x7f/0xf0  net/openvswitch/vport.c:139
     [&lt;00000000f9a04a7d&gt;] internal_dev_create+0x24/0x1d0  net/openvswitch/vport-internal_dev.c:164
     [&lt;0000000056ee7c13&gt;] ovs_vport_add+0x81/0x190  net/openvswitch/vport.c:199
     [&lt;000000005434efc7&gt;] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
     [&lt;00000000b7b253f1&gt;] ovs_dp_cmd_new+0x22f/0x410  net/openvswitch/datapath.c:1614
     [&lt;00000000e0988518&gt;] genl_family_rcv_msg+0x2ab/0x5b0  net/netlink/genetlink.c:629
     [&lt;00000000d0cc9347&gt;] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
     [&lt;000000006694b647&gt;] netlink_rcv_skb+0x61/0x170  net/netlink/af_netlink.c:2477
     [&lt;0000000088381f37&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
     [&lt;00000000dad42a47&gt;] netlink_unicast_kernel  net/netlink/af_netlink.c:1302 [inline]
     [&lt;00000000dad42a47&gt;] netlink_unicast+0x1ec/0x2d0  net/netlink/af_netlink.c:1328
     [&lt;0000000067e6b079&gt;] netlink_sendmsg+0x270/0x480  net/netlink/af_netlink.c:1917
     [&lt;00000000aab08a47&gt;] sock_sendmsg_nosec net/socket.c:637 [inline]
     [&lt;00000000aab08a47&gt;] sock_sendmsg+0x54/0x70 net/socket.c:657
     [&lt;000000004cb7c11d&gt;] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
     [&lt;00000000c4901c63&gt;] __sys_sendmsg+0x80/0xf0 net/socket.c:2356

BUG: memory leak
unreferenced object 0xffff8881228ca500 (size 128):
   comm "syz-executor032", pid 7015, jiffies 4294944622 (age 7.880s)
   hex dump (first 32 bytes):
     00 f0 27 18 81 88 ff ff 80 ac 8c 22 81 88 ff ff  ..'........"....
     40 b7 23 17 81 88 ff ff 00 00 00 00 00 00 00 00  @.#.............
   backtrace:
     [&lt;000000000eb78212&gt;] kmemleak_alloc_recursive  include/linux/kmemleak.h:43 [inline]
     [&lt;000000000eb78212&gt;] slab_post_alloc_hook mm/slab.h:522 [inline]
     [&lt;000000000eb78212&gt;] slab_alloc mm/slab.c:3319 [inline]
     [&lt;000000000eb78212&gt;] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
     [&lt;00000000006ea6c6&gt;] kmalloc include/linux/slab.h:552 [inline]
     [&lt;00000000006ea6c6&gt;] kzalloc include/linux/slab.h:748 [inline]
     [&lt;00000000006ea6c6&gt;] ovs_vport_alloc+0x37/0xf0  net/openvswitch/vport.c:130
     [&lt;00000000f9a04a7d&gt;] internal_dev_create+0x24/0x1d0  net/openvswitch/vport-internal_dev.c:164
     [&lt;0000000056ee7c13&gt;] ovs_vport_add+0x81/0x190  net/openvswitch/vport.c:199
     [&lt;000000005434efc7&gt;] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
     [&lt;00000000b7b253f1&gt;] ovs_dp_cmd_new+0x22f/0x410  net/openvswitch/datapath.c:1614
     [&lt;00000000e0988518&gt;] genl_family_rcv_msg+0x2ab/0x5b0  net/netlink/genetlink.c:629
     [&lt;00000000d0cc9347&gt;] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
     [&lt;000000006694b647&gt;] netlink_rcv_skb+0x61/0x170  net/netlink/af_netlink.c:2477
     [&lt;0000000088381f37&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
     [&lt;00000000dad42a47&gt;] netlink_unicast_kernel  net/netlink/af_netlink.c:1302 [inline]
     [&lt;00000000dad42a47&gt;] netlink_unicast+0x1ec/0x2d0  net/netlink/af_netlink.c:1328
     [&lt;0000000067e6b079&gt;] netlink_sendmsg+0x270/0x480  net/netlink/af_netlink.c:1917
     [&lt;00000000aab08a47&gt;] sock_sendmsg_nosec net/socket.c:637 [inline]
     [&lt;00000000aab08a47&gt;] sock_sendmsg+0x54/0x70 net/socket.c:657
     [&lt;000000004cb7c11d&gt;] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
     [&lt;00000000c4901c63&gt;] __sys_sendmsg+0x80/0xf0 net/socket.c:2356
     [&lt;00000000c10abb2d&gt;] __do_sys_sendmsg net/socket.c:2365 [inline]
     [&lt;00000000c10abb2d&gt;] __se_sys_sendmsg net/socket.c:2363 [inline]
     [&lt;00000000c10abb2d&gt;] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2363
=====================================================================

The function in net core, register_netdevice(), may fail with vport's
destruction callback either invoked or not. After commit 309b66970ee2
("net: openvswitch: do not free vport if register_netdevice() is failed."),
the duty to destroy vport is offloaded from the driver OTOH, which ends
up in the memory leak reported.

It is fixed by releasing vport unless device is registered successfully.
To do that, the callback assignment is defered until device is registered.

Reported-by: syzbot+13210896153522fe1ee5@syzkaller.appspotmail.com
Fixes: 309b66970ee2 ("net: openvswitch: do not free vport if register_netdevice() is failed.")
Cc: Taehee Yoo &lt;ap420073@gmail.com&gt;
Cc: Greg Rose &lt;gvrose8192@gmail.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Cc: Ying Xue &lt;ying.xue@windriver.com&gt;
Cc: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Signed-off-by: Hillf Danton &lt;hdanton@sina.com&gt;
Acked-by: Pravin B Shelar &lt;pshelar@ovn.org&gt;
[sbrivio: this was sent to dev@openvswitch.org and never made its way
 to netdev -- resending original patch]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
Reviewed-by: Greg Rose &lt;gvrose8192@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;jakub.kicinski@netronome.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: ipset: Fix an error code in ip_set_sockfn_get()</title>
<updated>2019-11-12T18:18:09+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2019-08-24T14:49:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ef1bf406881d61512911b56c77e96a1489f136b6'/>
<id>ef1bf406881d61512911b56c77e96a1489f136b6</id>
<content type='text'>
commit 30b7244d79651460ff114ba8f7987ed94c86b99a upstream.

The copy_to_user() function returns the number of bytes remaining to be
copied.  In this code, that positive return is checked at the end of the
function and we return zero/success.  What we should do instead is
return -EFAULT.

Fixes: a7b4f989a629 ("netfilter: ipset: IP set core support")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Jozsef Kadlecsik &lt;kadlec@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 30b7244d79651460ff114ba8f7987ed94c86b99a upstream.

The copy_to_user() function returns the number of bytes remaining to be
copied.  In this code, that positive return is checked at the end of the
function and we return zero/success.  What we should do instead is
return -EFAULT.

Fixes: a7b4f989a629 ("netfilter: ipset: IP set core support")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Jozsef Kadlecsik &lt;kadlec@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nfc: netlink: fix double device reference drop</title>
<updated>2019-11-12T18:17:54+00:00</updated>
<author>
<name>Pan Bian</name>
<email>bianpan2016@163.com</email>
</author>
<published>2019-11-07T06:29:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=6c234cb7fc9d948e2edb2c22804e14ea598640fb'/>
<id>6c234cb7fc9d948e2edb2c22804e14ea598640fb</id>
<content type='text'>
[ Upstream commit 025ec40b81d785a98f76b8bdb509ac10773b4f12 ]

The function nfc_put_device(dev) is called twice to drop the reference
to dev when there is no associated local llcp. Remove one of them to fix
the bug.

Fixes: 52feb444a903 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support")
Fixes: d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface")
Signed-off-by: Pan Bian &lt;bianpan2016@163.com&gt;
Reviewed-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 025ec40b81d785a98f76b8bdb509ac10773b4f12 ]

The function nfc_put_device(dev) is called twice to drop the reference
to dev when there is no associated local llcp. Remove one of them to fix
the bug.

Fixes: 52feb444a903 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support")
Fixes: d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface")
Signed-off-by: Pan Bian &lt;bianpan2016@163.com&gt;
Reviewed-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv4: Fix table id reference in fib_sync_down_addr</title>
<updated>2019-11-12T18:17:49+00:00</updated>
<author>
<name>David Ahern</name>
<email>dsahern@kernel.org</email>
</author>
<published>2019-11-07T18:29:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b0b4aca6d67d3ee3ed859d9df8bcd100328fb05c'/>
<id>b0b4aca6d67d3ee3ed859d9df8bcd100328fb05c</id>
<content type='text'>
[ Upstream commit e0a312629fefa943534fc46f7bfbe6de3fdaf463 ]

Hendrik reported routes in the main table using source address are not
removed when the address is removed. The problem is that fib_sync_down_addr
does not account for devices in the default VRF which are associated
with the main table. Fix by updating the table id reference.

Fixes: 5a56a0b3a45d ("net: Don't delete routes in different VRFs")
Reported-by: Hendrik Donner &lt;hd@os-cillation.de&gt;
Signed-off-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e0a312629fefa943534fc46f7bfbe6de3fdaf463 ]

Hendrik reported routes in the main table using source address are not
removed when the address is removed. The problem is that fib_sync_down_addr
does not account for devices in the default VRF which are associated
with the main table. Fix by updating the table id reference.

Fixes: 5a56a0b3a45d ("net: Don't delete routes in different VRFs")
Reported-by: Hendrik Donner &lt;hd@os-cillation.de&gt;
Signed-off-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/flow_dissector: switch to siphash</title>
<updated>2019-11-10T10:25:37+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2019-10-22T14:57:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=a9de6f42e945cdb24b59c7ab7ebad1eba6cb5875'/>
<id>a9de6f42e945cdb24b59c7ab7ebad1eba6cb5875</id>
<content type='text'>
commit 55667441c84fa5e0911a0aac44fb059c15ba6da2 upstream.

UDP IPv6 packets auto flowlabels are using a 32bit secret
(static u32 hashrnd in net/core/flow_dissector.c) and
apply jhash() over fields known by the receivers.

Attackers can easily infer the 32bit secret and use this information
to identify a device and/or user, since this 32bit secret is only
set at boot time.

Really, using jhash() to generate cookies sent on the wire
is a serious security concern.

Trying to change the rol32(hash, 16) in ip6_make_flowlabel() would be
a dead end. Trying to periodically change the secret (like in sch_sfq.c)
could change paths taken in the network for long lived flows.

Let's switch to siphash, as we did in commit df453700e8d8
("inet: switch IP ID generator to siphash")

Using a cryptographically strong pseudo random function will solve this
privacy issue and more generally remove other weak points in the stack.

Packet schedulers using skb_get_hash_perturb() benefit from this change.

Fixes: b56774163f99 ("ipv6: Enable auto flow labels by default")
Fixes: 42240901f7c4 ("ipv6: Implement different admin modes for automatic flow labels")
Fixes: 67800f9b1f4e ("ipv6: Call skb_get_hash_flowi6 to get skb-&gt;hash in ip6_make_flowlabel")
Fixes: cb1ce2ef387b ("ipv6: Implement automatic flow label generation on transmit")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Jonathan Berger &lt;jonathann1@walla.com&gt;
Reported-by: Amit Klein &lt;aksecurity@gmail.com&gt;
Reported-by: Benny Pinkas &lt;benny@pinkas.net&gt;
Cc: Tom Herbert &lt;tom@herbertland.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 55667441c84fa5e0911a0aac44fb059c15ba6da2 upstream.

UDP IPv6 packets auto flowlabels are using a 32bit secret
(static u32 hashrnd in net/core/flow_dissector.c) and
apply jhash() over fields known by the receivers.

Attackers can easily infer the 32bit secret and use this information
to identify a device and/or user, since this 32bit secret is only
set at boot time.

Really, using jhash() to generate cookies sent on the wire
is a serious security concern.

Trying to change the rol32(hash, 16) in ip6_make_flowlabel() would be
a dead end. Trying to periodically change the secret (like in sch_sfq.c)
could change paths taken in the network for long lived flows.

Let's switch to siphash, as we did in commit df453700e8d8
("inet: switch IP ID generator to siphash")

Using a cryptographically strong pseudo random function will solve this
privacy issue and more generally remove other weak points in the stack.

Packet schedulers using skb_get_hash_perturb() benefit from this change.

Fixes: b56774163f99 ("ipv6: Enable auto flow labels by default")
Fixes: 42240901f7c4 ("ipv6: Implement different admin modes for automatic flow labels")
Fixes: 67800f9b1f4e ("ipv6: Call skb_get_hash_flowi6 to get skb-&gt;hash in ip6_make_flowlabel")
Fixes: cb1ce2ef387b ("ipv6: Implement automatic flow label generation on transmit")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Jonathan Berger &lt;jonathann1@walla.com&gt;
Reported-by: Amit Klein &lt;aksecurity@gmail.com&gt;
Reported-by: Benny Pinkas &lt;benny@pinkas.net&gt;
Cc: Tom Herbert &lt;tom@herbertland.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>inet: stop leaking jiffies on the wire</title>
<updated>2019-11-10T10:25:37+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2019-11-01T17:32:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4fa6002a34db62f5a5d536f30fc9dedd1ce7ee84'/>
<id>4fa6002a34db62f5a5d536f30fc9dedd1ce7ee84</id>
<content type='text'>
[ Upstream commit a904a0693c189691eeee64f6c6b188bd7dc244e9 ]

Historically linux tried to stick to RFC 791, 1122, 2003
for IPv4 ID field generation.

RFC 6864 made clear that no matter how hard we try,
we can not ensure unicity of IP ID within maximum
lifetime for all datagrams with a given source
address/destination address/protocol tuple.

Linux uses a per socket inet generator (inet_id), initialized
at connection startup with a XOR of 'jiffies' and other
fields that appear clear on the wire.

Thiemo Nagel pointed that this strategy is a privacy
concern as this provides 16 bits of entropy to fingerprint
devices.

Let's switch to a random starting point, this is just as
good as far as RFC 6864 is concerned and does not leak
anything critical.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Thiemo Nagel &lt;tnagel@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a904a0693c189691eeee64f6c6b188bd7dc244e9 ]

Historically linux tried to stick to RFC 791, 1122, 2003
for IPv4 ID field generation.

RFC 6864 made clear that no matter how hard we try,
we can not ensure unicity of IP ID within maximum
lifetime for all datagrams with a given source
address/destination address/protocol tuple.

Linux uses a per socket inet generator (inet_id), initialized
at connection startup with a XOR of 'jiffies' and other
fields that appear clear on the wire.

Thiemo Nagel pointed that this strategy is a privacy
concern as this provides 16 bits of entropy to fingerprint
devices.

Let's switch to a random starting point, this is just as
good as far as RFC 6864 is concerned and does not leak
anything critical.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Thiemo Nagel &lt;tnagel@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erspan: fix the tun_info options_len check for erspan</title>
<updated>2019-11-10T10:25:36+00:00</updated>
<author>
<name>Xin Long</name>
<email>lucien.xin@gmail.com</email>
</author>
<published>2019-10-28T15:19:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b0c64eda9996479c9b135c23f5b18a0314af4a98'/>
<id>b0c64eda9996479c9b135c23f5b18a0314af4a98</id>
<content type='text'>
[ Upstream commit 2eb8d6d2910cfe3dc67dc056f26f3dd9c63d47cd ]

The check for !md doens't really work for ip_tunnel_info_opts(info) which
only does info + 1. Also to avoid out-of-bounds access on info, it should
ensure options_len is not less than erspan_metadata in both erspan_xmit()
and ip6erspan_tunnel_xmit().

Fixes: 1a66a836da ("gre: add collect_md mode to ERSPAN tunnel")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2eb8d6d2910cfe3dc67dc056f26f3dd9c63d47cd ]

The check for !md doens't really work for ip_tunnel_info_opts(info) which
only does info + 1. Also to avoid out-of-bounds access on info, it should
ensure options_len is not less than erspan_metadata in both erspan_xmit()
and ip6erspan_tunnel_xmit().

Fixes: 1a66a836da ("gre: add collect_md mode to ERSPAN tunnel")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: use skb_queue_empty_lockless() in busy poll contexts</title>
<updated>2019-11-10T10:25:35+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2019-10-24T05:44:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=0d50fc2bb4c748951c05280716113cffc3efbb7f'/>
<id>0d50fc2bb4c748951c05280716113cffc3efbb7f</id>
<content type='text'>
[ Upstream commit 3f926af3f4d688e2e11e7f8ed04e277a14d4d4a4 ]

Busy polling usually runs without locks.
Let's use skb_queue_empty_lockless() instead of skb_queue_empty()

Also uses READ_ONCE() in __skb_try_recv_datagram() to address
a similar potential problem.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3f926af3f4d688e2e11e7f8ed04e277a14d4d4a4 ]

Busy polling usually runs without locks.
Let's use skb_queue_empty_lockless() instead of skb_queue_empty()

Also uses READ_ONCE() in __skb_try_recv_datagram() to address
a similar potential problem.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
