osmocom-net-gprs October 2024

osmocom-net-gprs@lists.osmocom.org

6 participants
3 discussions

[syzbot] [net?] possible deadlock in gtp_encap_enable_socket
by syzbot 13 May '25

13 May '25

Hello, syzbot found the following issue on: HEAD commit: 9410645520e9 Merge tag 'net-next-6.12' of git://git.kernel.. git tree: net-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=15d39e9f980000 kernel config: https://syzkaller.appspot.com/x/.config?x=37c006d80708398d dashboard link: https://syzkaller.appspot.com/bug?extid=e953a8f3071f5c0a28fd compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16215ca9980000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=110c6c27980000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/80466d230dfb/disk-94106455.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/ba253eabab42/vmlinux-94106455.… kernel image: https://storage.googleapis.com/syzbot-assets/569982fb6c88/bzImage-94106455.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e953a8f3071f5c0a28fd(a)syzkaller.appspotmail.com IPVS: Unknown mcast interface: macvlan0 netlink: 8 bytes leftover after parsing attributes in process `syz-executor297'. netlink: 24 bytes leftover after parsing attributes in process `syz-executor297'. ====================================================== WARNING: possible circular locking dependency detected 6.11.0-syzkaller-01458-g9410645520e9 #0 Not tainted ------------------------------------------------------ syz-executor297/5243 is trying to acquire lock: ffff88801cf99158 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1609 [inline] ffff88801cf99158 (sk_lock-AF_INET){+.+.}-{0:0}, at: gtp_encap_enable_socket+0x2ce/0x5c0 drivers/net/gtp.c:1674 but task is already holding lock: ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:79 [inline] ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x6e6/0xcf0 net/core/rtnetlink.c:6643 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (rtnl_mutex){+.+.}-{3:3}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 start_sync_thread+0xdc/0x2dc0 net/netfilter/ipvs/ip_vs_sync.c:1761 do_ip_vs_set_ctl+0x442/0x13d0 net/netfilter/ipvs/ip_vs_ctl.c:2732 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 smc_setsockopt+0x275/0xe50 net/smc/af_smc.c:3064 do_sock_setsockopt+0x3af/0x720 net/socket.c:2330 __sys_setsockopt+0x1ae/0x250 net/socket.c:2353 __do_sys_setsockopt net/socket.c:2362 [inline] __se_sys_setsockopt net/socket.c:2359 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2359 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 (&smc->clcsock_release_lock){+.+.}-{3:3}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 smc_switch_to_fallback+0x35/0xdb0 net/smc/af_smc.c:902 smc_sendmsg+0x11f/0x530 net/smc/af_smc.c:2771 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2603 ___sys_sendmsg net/socket.c:2657 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2686 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (sk_lock-AF_INET){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3133 [inline] check_prevs_add kernel/locking/lockdep.c:3252 [inline] validate_chain+0x18e0/0x5900 kernel/locking/lockdep.c:3868 __lock_acquire+0x137a/0x2040 kernel/locking/lockdep.c:5142 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 lock_sock_nested+0x48/0x100 net/core/sock.c:3611 lock_sock include/net/sock.h:1609 [inline] gtp_encap_enable_socket+0x2ce/0x5c0 drivers/net/gtp.c:1674 gtp_encap_enable drivers/net/gtp.c:1707 [inline] gtp_newlink+0x589/0xf30 drivers/net/gtp.c:1511 rtnl_newlink_create net/core/rtnetlink.c:3510 [inline] __rtnl_newlink net/core/rtnetlink.c:3730 [inline] rtnl_newlink+0x1591/0x20a0 net/core/rtnetlink.c:3743 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6646 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2603 ___sys_sendmsg net/socket.c:2657 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2686 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Chain exists of: sk_lock-AF_INET --> &smc->clcsock_release_lock --> rtnl_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(&smc->clcsock_release_lock); lock(rtnl_mutex); lock(sk_lock-AF_INET); *** DEADLOCK *** 1 lock held by syz-executor297/5243: #0: ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:79 [inline] #0: ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x6e6/0xcf0 net/core/rtnetlink.c:6643 stack backtrace: CPU: 0 UID: 0 PID: 5243 Comm: syz-executor297 Not tainted 6.11.0-syzkaller-01458-g9410645520e9 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2186 check_prev_add kernel/locking/lockdep.c:3133 [inline] check_prevs_add kernel/locking/lockdep.c:3252 [inline] validate_chain+0x18e0/0x5900 kernel/locking/lockdep.c:3868 __lock_acquire+0x137a/0x2040 kernel/locking/lockdep.c:5142 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 lock_sock_nested+0x48/0x100 net/core/sock.c:3611 lock_sock include/net/sock.h:1609 [inline] gtp_encap_enable_socket+0x2ce/0x5c0 drivers/net/gtp.c:1674 gtp_encap_enable drivers/net/gtp.c:1707 [inline] gtp_newlink+0x589/0xf30 drivers/net/gtp.c:1511 rtnl_newlink_create net/core/rtnetlink.c:3510 [inline] __rtnl_newlink net/core/rtnetlink.c:3730 [inline] rtnl_newlink+0x1591/0x20a0 net/core/rtnetlink.c:3743 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6646 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2603 ___sys_sendmsg net/socket.c:2657 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2686 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fed198844a9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RS --- This report 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(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

3 3

[PATCH net] gtp: allow -1 to be specified as file description from userspace
by Pablo Neira Ayuso 29 Oct '24

29 Oct '24

Existing user space applications maintained by the Osmocom project are breaking since a recent fix that addresses incorrect error checking. Restore operation for user space programs that specify -1 as file descriptor to skip GTPv0 or GTPv1 only sockets. Fixes: defd8b3c37b0 ("gtp: fix a potential NULL pointer dereference") Reported-by: Pau Espin Pedrol <pespin(a)sysmocom.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> --- drivers/net/gtp.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index a60bfb1abb7f..70f981887518 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1702,20 +1702,24 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) return -EINVAL; if (data[IFLA_GTP_FD0]) { - u32 fd0 = nla_get_u32(data[IFLA_GTP_FD0]); + int fd0 = nla_get_u32(data[IFLA_GTP_FD0]); - sk0 = gtp_encap_enable_socket(fd0, UDP_ENCAP_GTP0, gtp); - if (IS_ERR(sk0)) - return PTR_ERR(sk0); + if (fd0 >= 0) { + sk0 = gtp_encap_enable_socket(fd0, UDP_ENCAP_GTP0, gtp); + if (IS_ERR(sk0)) + return PTR_ERR(sk0); + } } if (data[IFLA_GTP_FD1]) { - u32 fd1 = nla_get_u32(data[IFLA_GTP_FD1]); + int fd1 = nla_get_u32(data[IFLA_GTP_FD1]); - sk1u = gtp_encap_enable_socket(fd1, UDP_ENCAP_GTP1U, gtp); - if (IS_ERR(sk1u)) { - gtp_encap_disable_sock(sk0); - return PTR_ERR(sk1u); + if (fd1 >= 0) { + sk1u = gtp_encap_enable_socket(fd1, UDP_ENCAP_GTP1U, gtp); + if (IS_ERR(sk1u)) { + gtp_encap_disable_sock(sk0); + return PTR_ERR(sk1u); + } } } -- 2.30.2

4 3

libgtp API strategy for Gn (SGSN <> MME)
by Alexander 'lynxis' Couzens 22 Oct '24

22 Oct '24

Hi, I'm currently looking into extending the libgtp interface to support Gn. Gn will be used between a SGSN and a MME to transfer UE state. This allows a UE to have mobility between 2G/3G network served by an SGSN and a 4G network served by an MME. It is based on GTPv1 TS 29.060 and to simply contains 3 PDUs: - 7.5.3 SGSN Context Request, - 7.5.4 SGSN Context Response - 7.5.5 SGSN Context Ack It can work in both direction for UE from 2G to 4G as well 4G to 2G. The SGSN Context Request creates its own GTP session by exchanging a TEID-C in the SGSN Req + Resp. E.g.: MME -> SGSN: SGSN Context Request (TEID 0, new TEID A) MME <- SGSN: SGSN Context Response (TEID A, new TEID B) MME -> SGSN: SGSN Context Ack (TEID B) But the API of libgtp is currently very high level, except for RAN Info Relay, a user doesn't interact with the GTP TLVs, instead it is using a struct and converts between each other. Libgtp was developed with GTPv0/v1 in mind to support requesting PDP Context for 2G (and later got extended to support 3G). Also the SGSN Context Response contains a very long list of optional TLVs (e.g. 27 in Rel 12), some of the TLVs also contain nested TLVs. So what is the right direction? Should I create a new high level API, parse only the 3-4 TLVs the SGSN will use into a `struct sgsn_response`? Also the state tracking of a request would be tracked then by GTP and passed as identifier to it. Or it could pass it to the SGSN and the SGSN has to take care of everything (except general message and tlv validation, parsing)? Best, lynxis

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs October 2024