linux-stable.git/drivers/net/tun.c, branch linux-6.16.y

net: tun: Update napi->skb after XDP process

2025-10-02T11:48:30+00:00

[ Upstream commit 1091860a16a86ccdd77c09f2b21a5f634f5ab9ec ]

The syzbot report a UAF issue:

  BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline]
  BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline]
  BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758
  Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079
  CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
  Call Trace:
   
   dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
   print_address_description mm/kasan/report.c:378 [inline]
   print_report+0xca/0x240 mm/kasan/report.c:482
   kasan_report+0x118/0x150 mm/kasan/report.c:595
   skb_reset_mac_header include/linux/skbuff.h:3150 [inline]
   napi_frags_skb net/core/gro.c:723 [inline]
   napi_gro_frags+0x6e/0x1030 net/core/gro.c:758
   tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920
   tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
   new_sync_write fs/read_write.c:593 [inline]
   vfs_write+0x5c9/0xb30 fs/read_write.c:686
   ksys_write+0x145/0x250 fs/read_write.c:738
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
   

  Allocated by task 6079:
   kasan_save_stack mm/kasan/common.c:47 [inline]
   kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
   unpoison_slab_object mm/kasan/common.c:330 [inline]
   __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558
   kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline]
   napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295
   __alloc_skb+0x11e/0x2d0 net/core/skbuff.c:657
   napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811
   napi_get_frags+0x69/0x140 net/core/gro.c:673
   tun_napi_alloc_frags drivers/net/tun.c:1404 [inline]
   tun_get_user+0x77c/0x3e20 drivers/net/tun.c:1784
   tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
   new_sync_write fs/read_write.c:593 [inline]
   vfs_write+0x5c9/0xb30 fs/read_write.c:686
   ksys_write+0x145/0x250 fs/read_write.c:738
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

  Freed by task 6079:
   kasan_save_stack mm/kasan/common.c:47 [inline]
   kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
   kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
   poison_slab_object mm/kasan/common.c:243 [inline]
   __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275
   kasan_slab_free include/linux/kasan.h:233 [inline]
   slab_free_hook mm/slub.c:2422 [inline]
   slab_free mm/slub.c:4695 [inline]
   kmem_cache_free+0x18f/0x400 mm/slub.c:4797
   skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969
   netif_skb_check_for_xdp net/core/dev.c:5390 [inline]
   netif_receive_generic_xdp net/core/dev.c:5431 [inline]
   do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499
   tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872
   tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
   new_sync_write fs/read_write.c:593 [inline]
   vfs_write+0x5c9/0xb30 fs/read_write.c:686
   ksys_write+0x145/0x250 fs/read_write.c:738
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

After commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in
generic mode"), the original skb may be freed in skb_pp_cow_data() when
XDP program was attached, which was allocated in tun_napi_alloc_frags().
However, the napi->skb still point to the original skb, update it after
XDP process.

Reported-by: syzbot+64e24275ad95a915a313@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=64e24275ad95a915a313
Fixes: e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in generic mode")
Signed-off-by: Wang Liang 
Reviewed-by: Willem de Bruijn 
Link: https://patch.msgid.link/20250917113919.3991267-1-wangliang74@huawei.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37+00:00

Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

net: core: Convert dev_set_mac_address_user() to use struct sockaddr_storage

2025-05-27T06:25:43+00:00

Convert callers of dev_set_mac_address_user() to use struct
sockaddr_storage. Add sanity checks on dev->addr_len usage.

Signed-off-by: Kees Cook 
Acked-by: Gustavo A. R. Silva 
Link: https://patch.msgid.link/20250521204619.2301870-8-kees@kernel.org
Signed-off-by: Paolo Abeni

treewide: Switch/rename to timer_delete[_sync]()

2025-04-05T08:30:12+00:00

timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.

Conversion was done with coccinelle plus manual fixups where necessary.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar

Revert "net: replace dev_addr_sem with netdev instance lock"

2025-03-19T17:52:00+00:00

This reverts commit df43d8bf10316a7c3b1e47e3cc0057a54df4a5b8.

Cc: Kohei Enju 
Reviewed-by: Kuniyuki Iwashima 
Fixes: df43d8bf1031 ("net: replace dev_addr_sem with netdev instance lock")
Signed-off-by: Stanislav Fomichev 
Link: https://patch.msgid.link/20250312190513.1252045-2-sdf@fomichev.me
Tested-by: Lei Yang 
Signed-off-by: Paolo Abeni

Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next

2025-03-08T03:08:49+00:00

Martin KaFai Lau says:

====================
pull-request: bpf-next 2025-03-06

We've added 6 non-merge commits during the last 13 day(s) which contain
a total of 6 files changed, 230 insertions(+), 56 deletions(-).

The main changes are:

1) Add XDP metadata support for tun driver, from Marcus Wichelmann.

* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next:
  selftests/bpf: Fix file descriptor assertion in open_tuntap helper
  selftests/bpf: Add test for XDP metadata support in tun driver
  selftests/bpf: Refactor xdp_context_functional test and bpf program
  selftests/bpf: Move open_tuntap to network helpers
  net: tun: Enable transfer of XDP metadata to skb
  net: tun: Enable XDP metadata support
====================

Link: https://patch.msgid.link/20250307055335.441298-1-martin.lau@linux.dev
Signed-off-by: Jakub Kicinski

net: replace dev_addr_sem with netdev instance lock

2025-03-06T20:59:45+00:00

Lockdep reports possible circular dependency in [0]. Instead of
fixing the ordering, replace global dev_addr_sem with netdev
instance lock. Most of the paths that set/get mac are RTNL
protected. Two places where it's not, convert to explicit
locking:
- sysfs address_show
- dev_get_mac_address via dev_ioctl

0: https://netdev-3.bots.linux.dev/vmksft-forwarding-dbg/results/993321/24-router-bridge-1d-lag-sh/stderr

Signed-off-by: Stanislav Fomichev 
Link: https://patch.msgid.link/20250305163732.2766420-12-sdf@fomichev.me
Signed-off-by: Jakub Kicinski

net: tun: Enable transfer of XDP metadata to skb

2025-03-06T20:31:08+00:00

When the XDP metadata area was used, it is expected that the same
metadata can also be accessed from TC, as can be read in the description
of the bpf_xdp_adjust_meta helper function. In the tun driver, this was
not yet implemented.

To make this work, the skb that is being built on XDP_PASS should know
of the current size of the metadata area. This is ensured by adding
calls to skb_metadata_set. For the tun_xdp_one code path, an additional
check is necessary to handle the case where the externally initialized
xdp_buff has no metadata support (xdp->data_meta == xdp->data + 1).

More information about this feature can be found in the commit message
of commit de8f3a83b0a0 ("bpf: add meta pointer for direct access").

Signed-off-by: Marcus Wichelmann 
Signed-off-by: Martin KaFai Lau 
Reviewed-by: Willem de Bruijn 
Acked-by: Jason Wang 
Link: https://patch.msgid.link/20250305213438.3863922-3-marcus.wichelmann@hetzner-cloud.de

net: tun: Enable XDP metadata support

2025-03-06T20:31:07+00:00

Enable the support for the bpf_xdp_adjust_meta helper function for XDP
buffers initialized by the tun driver. This allows to reserve a metadata
area that is useful to pass any information from one XDP program to
another one, for example when using tail-calls.

Whether this helper function can be used in an XDP program depends on
how the xdp_buff was initialized. Most net drivers initialize the
xdp_buff in a way, that allows bpf_xdp_adjust_meta to be used. In case
of the tun driver, this is currently not the case.

There are two code paths in the tun driver that lead to a
bpf_prog_run_xdp and where metadata support should be enabled:

1. tun_build_skb, which is called by tun_get_user and is used when
   writing packets from userspace into the device. In this case, the
   xdp_buff created in tun_build_skb has no support for
   bpf_xdp_adjust_meta and calls of that helper function result in
   ENOTSUPP.

   For this code path, it's sufficient to set the meta_valid argument of
   the xdp_prepare_buff call. The reserved headroom is large enough
   already.

2. tun_xdp_one, which is called by tun_sendmsg which again is called by
   other drivers (e.g. vhost_net). When the TUN_MSG_PTR mode is used,
   another driver may pass a batch of xdp_buffs to the tun driver. In
   this case, that other driver is the one initializing the xdp_buff.

   See commit 043d222f93ab ("tuntap: accept an array of XDP buffs
   through sendmsg()") for details.

   For now, the vhost_net driver is the only one using TUN_MSG_PTR and
   it already initializes the xdp_buffs with metadata support and
   sufficient headroom. But the tun driver disables it again, so the
   xdp_set_data_meta_invalid call has to be removed.

Signed-off-by: Marcus Wichelmann 
Signed-off-by: Martin KaFai Lau 
Acked-by: Jason Wang 
Link: https://patch.msgid.link/20250305213438.3863922-2-marcus.wichelmann@hetzner-cloud.de

tun: Extract the vnet handling code

2025-02-11T03:07:11+00:00

The vnet handling code will be reused by tap.

Functions are renamed to ensure that their names contain "vnet" to
clarify that they are part of the decoupled vnet handling code.

Signed-off-by: Akihiko Odaki 
Reviewed-by: Willem de Bruijn 
Link: https://patch.msgid.link/20250207-tun-v6-5-fb49cf8b103e@daynix.com
Signed-off-by: Jakub Kicinski