<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/net/vxlan, branch linux-6.0.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-6.0.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-6.0.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2023-01-12T11:00:39+00:00</updated>
<entry>
<title>vxlan: Fix memory leaks in error path</title>
<updated>2023-01-12T11:00:39+00:00</updated>
<author>
<name>Ido Schimmel</name>
<email>idosch@nvidia.com</email>
</author>
<published>2023-01-02T06:55:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=75c1ab900f7cf0485f0be1607c79c55f51faaa90'/>
<id>urn:sha1:75c1ab900f7cf0485f0be1607c79c55f51faaa90</id>
<content type='text'>
[ Upstream commit 06bf62944144a92d83dd14fd1378d2a288259561 ]

The memory allocated by vxlan_vnigroup_init() is not freed in the error
path, leading to memory leaks [1]. Fix by calling
vxlan_vnigroup_uninit() in the error path.

The leaks can be reproduced by annotating gro_cells_init() with
ALLOW_ERROR_INJECTION() and then running:

 # echo "100" &gt; /sys/kernel/debug/fail_function/probability
 # echo "1" &gt; /sys/kernel/debug/fail_function/times
 # echo "gro_cells_init" &gt; /sys/kernel/debug/fail_function/inject
 # printf %#x -12 &gt; /sys/kernel/debug/fail_function/gro_cells_init/retval
 # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter
 RTNETLINK answers: Cannot allocate memory

[1]
unreferenced object 0xffff88810db84a00 (size 512):
  comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
  hex dump (first 32 bytes):
    f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02  ..v.............
    03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00  ....H...........
  backtrace:
    [&lt;ffffffff81a3097a&gt;] kmalloc_trace+0x2a/0x60
    [&lt;ffffffff82f049fc&gt;] vxlan_vnigroup_init+0x4c/0x160
    [&lt;ffffffff82ecd69e&gt;] vxlan_init+0x1ae/0x280
    [&lt;ffffffff836858ca&gt;] register_netdevice+0x57a/0x16d0
    [&lt;ffffffff82ef67b7&gt;] __vxlan_dev_create+0x7c7/0xa50
    [&lt;ffffffff82ef6ce6&gt;] vxlan_newlink+0xd6/0x130
    [&lt;ffffffff836d02ab&gt;] __rtnl_newlink+0x112b/0x18a0
    [&lt;ffffffff836d0a8c&gt;] rtnl_newlink+0x6c/0xa0
    [&lt;ffffffff836c0ddf&gt;] rtnetlink_rcv_msg+0x43f/0xd40
    [&lt;ffffffff83908ce0&gt;] netlink_rcv_skb+0x170/0x440
    [&lt;ffffffff839066af&gt;] netlink_unicast+0x53f/0x810
    [&lt;ffffffff839072d8&gt;] netlink_sendmsg+0x958/0xe70
    [&lt;ffffffff835c319f&gt;] ____sys_sendmsg+0x78f/0xa90
    [&lt;ffffffff835cd6da&gt;] ___sys_sendmsg+0x13a/0x1e0
    [&lt;ffffffff835cd94c&gt;] __sys_sendmsg+0x11c/0x1f0
    [&lt;ffffffff8424da78&gt;] do_syscall_64+0x38/0x80
unreferenced object 0xffff88810e76d5f8 (size 192):
  comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
  hex dump (first 32 bytes):
    04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00  ..........O.....
    08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff  ..v.......v.....
  backtrace:
    [&lt;ffffffff81a3162e&gt;] __kmalloc_node+0x4e/0x90
    [&lt;ffffffff81a0e166&gt;] kvmalloc_node+0xa6/0x1f0
    [&lt;ffffffff8276e1a3&gt;] bucket_table_alloc.isra.0+0x83/0x460
    [&lt;ffffffff8276f18b&gt;] rhashtable_init+0x43b/0x7c0
    [&lt;ffffffff82f04a1c&gt;] vxlan_vnigroup_init+0x6c/0x160
    [&lt;ffffffff82ecd69e&gt;] vxlan_init+0x1ae/0x280
    [&lt;ffffffff836858ca&gt;] register_netdevice+0x57a/0x16d0
    [&lt;ffffffff82ef67b7&gt;] __vxlan_dev_create+0x7c7/0xa50
    [&lt;ffffffff82ef6ce6&gt;] vxlan_newlink+0xd6/0x130
    [&lt;ffffffff836d02ab&gt;] __rtnl_newlink+0x112b/0x18a0
    [&lt;ffffffff836d0a8c&gt;] rtnl_newlink+0x6c/0xa0
    [&lt;ffffffff836c0ddf&gt;] rtnetlink_rcv_msg+0x43f/0xd40
    [&lt;ffffffff83908ce0&gt;] netlink_rcv_skb+0x170/0x440
    [&lt;ffffffff839066af&gt;] netlink_unicast+0x53f/0x810
    [&lt;ffffffff839072d8&gt;] netlink_sendmsg+0x958/0xe70
    [&lt;ffffffff835c319f&gt;] ____sys_sendmsg+0x78f/0xa90

Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")
Signed-off-by: Ido Schimmel &lt;idosch@nvidia.com&gt;
Reviewed-by: Nikolay Aleksandrov &lt;razor@blackwall.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vxlan: do not use RT_TOS for IPv6 flowlabel</title>
<updated>2022-08-10T05:19:20+00:00</updated>
<author>
<name>Matthias May</name>
<email>matthias.may@westermo.com</email>
</author>
<published>2022-08-05T19:19:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e488d4f5d6e4cd1e728ba4ddbdcd7ef5f4d13a21'/>
<id>urn:sha1:e488d4f5d6e4cd1e728ba4ddbdcd7ef5f4d13a21</id>
<content type='text'>
According to Guillaume Nault RT_TOS should never be used for IPv6.

Quote:
RT_TOS() is an old macro used to interprete IPv4 TOS as described in
the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
code, although, given the current state of the code, most of the
existing calls have no consequence.

But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
field to be interpreted the RFC 1349 way. There's no historical
compatibility to worry about.

Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class")
Acked-by: Guillaume Nault &lt;gnault@redhat.com&gt;
Signed-off-by: Matthias May &lt;matthias.may@westermo.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>vxlan: Use ip_tunnel_key flow flags in route lookups</title>
<updated>2022-07-26T10:43:16+00:00</updated>
<author>
<name>Paul Chaignon</name>
<email>paul@isovalent.com</email>
</author>
<published>2022-07-25T14:31:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e2fb8bc7ef6c7a63ca95751b90162dece0b3f4c'/>
<id>urn:sha1:7e2fb8bc7ef6c7a63ca95751b90162dece0b3f4c</id>
<content type='text'>
Use the new ip_tunnel_key field with the flow flags in the IPv4 route
lookups for the encapsulated packet. This will be used by the
bpf_skb_set_tunnel_key helper in a subsequent commit.

Signed-off-by: Paul Chaignon &lt;paul@isovalent.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Nikolay Aleksandrov &lt;razor@blackwall.org&gt;
Acked-by: Martin KaFai Lau &lt;kafai@fb.com&gt;
Link: https://lore.kernel.org/bpf/1ffc95c3d60182fd5ec0cf6602083f8f68afe98f.1658759380.git.paul@isovalent.com
</content>
</entry>
<entry>
<title>net: adopt u64_stats_t in struct pcpu_sw_netstats</title>
<updated>2022-06-10T04:53:11+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2022-06-08T15:46:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9962acefbcb92736c268aafe5f52200948f60f3e'/>
<id>urn:sha1:9962acefbcb92736c268aafe5f52200948f60f3e</id>
<content type='text'>
As explained in commit 316580b69d0a ("u64_stats: provide u64_stats_t type")
we should use u64_stats_t and related accessors to avoid load/store tearing.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: vxlan: Fix kernel coding style</title>
<updated>2022-05-21T00:38:27+00:00</updated>
<author>
<name>Alaa Mohamed</name>
<email>eng.alaamohamedsoliman.am@gmail.com</email>
</author>
<published>2022-05-20T00:36:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c2e10f53455c898050738d6a5f8c237f27aec225'/>
<id>urn:sha1:c2e10f53455c898050738d6a5f8c237f27aec225</id>
<content type='text'>
The continuation line does not align with the opening bracket
and this patch fix it.

Signed-off-by: Alaa Mohamed &lt;eng.alaamohamedsoliman.am@gmail.com&gt;
Link: https://lore.kernel.org/r/20220520003614.6073-1-eng.alaamohamedsoliman.am@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: vxlan: Add extack support to vxlan_fdb_delete</title>
<updated>2022-05-09T10:58:20+00:00</updated>
<author>
<name>Alaa Mohamed</name>
<email>eng.alaamohamedsoliman.am@gmail.com</email>
</author>
<published>2022-05-05T15:09:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e92695e506d663bc4868ffc5bc187488a4f4d5c8'/>
<id>urn:sha1:e92695e506d663bc4868ffc5bc187488a4f4d5c8</id>
<content type='text'>
This patch adds extack msg support to vxlan_fdb_delete and vxlan_fdb_parse.
extack is used to propagate meaningful error msgs to the user of vxlan
fdb netlink api

Signed-off-by: Alaa Mohamed &lt;eng.alaamohamedsoliman.am@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>rtnetlink: add extack support in fdb del handlers</title>
<updated>2022-05-09T10:58:20+00:00</updated>
<author>
<name>Alaa Mohamed</name>
<email>eng.alaamohamedsoliman.am@gmail.com</email>
</author>
<published>2022-05-05T15:09:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ca4567f1e6f660f86fcd04f3563c0045b0d4772f'/>
<id>urn:sha1:ca4567f1e6f660f86fcd04f3563c0045b0d4772f</id>
<content type='text'>
Add extack support to .ndo_fdb_del in netdevice.h and
all related methods.

Signed-off-by: Alaa Mohamed &lt;eng.alaamohamedsoliman.am@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: add netif_inherit_tso_max()</title>
<updated>2022-05-06T11:07:56+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-05-06T02:51:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6df6398f7c8b481ce83f28143bc08a5231616deb'/>
<id>urn:sha1:6df6398f7c8b481ce83f28143bc08a5231616deb</id>
<content type='text'>
To make later patches smaller create a helper for inheriting
the TSO limitations of a lower device. The TSO in the name
is not an accident, subsequent patches will replace GSO
with TSO in more names.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>vxlan: fix error return code in vxlan_fdb_append</title>
<updated>2022-04-08T11:35:12+00:00</updated>
<author>
<name>Hongbin Wang</name>
<email>wh_bin@126.com</email>
</author>
<published>2022-04-07T02:46:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7cea5560bf656b84f9ed01c0cc829d4eecd0640b'/>
<id>urn:sha1:7cea5560bf656b84f9ed01c0cc829d4eecd0640b</id>
<content type='text'>
When kmalloc and dst_cache_init failed,
should return ENOMEM rather than ENOBUFS.

Signed-off-by: Hongbin Wang &lt;wh_bin@126.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>vxlan: do not feed vxlan_vnifilter_dump_dev with non vxlan devices</title>
<updated>2022-03-31T15:53:01+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2022-03-30T19:46:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9d570741aec1e1ebd37823b34a2958f24809ff24'/>
<id>urn:sha1:9d570741aec1e1ebd37823b34a2958f24809ff24</id>
<content type='text'>
vxlan_vnifilter_dump_dev() assumes it is called only
for vxlan devices. Make sure it is the case.

BUG: KASAN: slab-out-of-bounds in vxlan_vnifilter_dump_dev+0x9a0/0xb40 drivers/net/vxlan/vxlan_vnifilter.c:349
Read of size 4 at addr ffff888060d1ce70 by task syz-executor.3/17662

CPU: 0 PID: 17662 Comm: syz-executor.3 Tainted: G        W         5.17.0-syzkaller-12888-g77c9387c0c5b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313
 print_report mm/kasan/report.c:429 [inline]
 kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
 vxlan_vnifilter_dump_dev+0x9a0/0xb40 drivers/net/vxlan/vxlan_vnifilter.c:349
 vxlan_vnifilter_dump+0x3ff/0x650 drivers/net/vxlan/vxlan_vnifilter.c:428
 netlink_dump+0x4b5/0xb70 net/netlink/af_netlink.c:2270
 __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2375
 netlink_dump_start include/linux/netlink.h:245 [inline]
 rtnetlink_rcv_msg+0x70c/0xb80 net/core/rtnetlink.c:5953
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:705 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:725
 ____sys_sendmsg+0x6e2/0x800 net/socket.c:2413
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2467
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f87b8e89049

Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Acked-by: Roopa Prabhu &lt;roopa@nvidia.com&gt;
Link: https://lore.kernel.org/r/20220330194643.2706132-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
