qiurui
/
Centos-kernel-stream-9
mirror of https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
1,167,572 Commits 5 Branches 2,211 Tags 2.6 GiB
Commit Graph

5 Commits

Author SHA1 Message Date
Davide Caratti 8ae51a7dcd mptcp: correct MPTCP_SUBFLOW_ATTR_SSN_OFFSET reserved size 
JIRA: https://issues.redhat.com/browse/RHEL-62871
Upstream Status: net.git commit 655111b838cdabdb604f3625a9ff08c5eedb11da

commit 655111b838cdabdb604f3625a9ff08c5eedb11da
Author: Eugene Syromiatnikov <esyr@redhat.com>
Date:   Mon Aug 12 08:51:23 2024 +0200

    mptcp: correct MPTCP_SUBFLOW_ATTR_SSN_OFFSET reserved size

    ssn_offset field is u32 and is placed into the netlink response with
    nla_put_u32(), but only 2 bytes are reserved for the attribute payload
    in subflow_get_info_size() (even though it makes no difference
    in the end, as it is aligned up to 4 bytes).  Supply the correct
    argument to the relevant nla_total_size() call to make it less
    confusing.

    Fixes: 5147dfb508 ("mptcp: allow dumping subflow context to userspace")
    Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240812065024.GA19719@asgard.redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Davide Caratti <dcaratti@redhat.com>
 2024-11-12 10:19:00 +01:00
Davide Caratti 41d3513051 mptcp: fix possible deadlock in subflow diag 
JIRA: https://issues.redhat.com/browse/RHEL-32669
CVE: CVE-2024-26781
Upstream Status: net.git commit d6a9608af9a75d13243d217f6ce1e30e57d56ffe

commit d6a9608af9a75d13243d217f6ce1e30e57d56ffe
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri Feb 23 17:14:19 2024 +0100

    mptcp: fix possible deadlock in subflow diag

    Syzbot and Eric reported a lockdep splat in the subflow diag:

       WARNING: possible circular locking dependency detected
       6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted

       syz-executor.2/24141 is trying to acquire lock:
       ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:
       tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]
       ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:
       tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137

       but task is already holding lock:
       ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock
       include/linux/spinlock.h:351 [inline]
       ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at:
       inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038

       which lock already depends on the new lock.

       the existing dependency chain (in reverse order) is:

       -> #1 (&h->lhash2[i].lock){+.+.}-{2:2}:
       lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
       __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
       _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
       spin_lock include/linux/spinlock.h:351 [inline]
       __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743
       inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261
       __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217
       inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239
       rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316
       rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577
       ops_init+0x352/0x610 net/core/net_namespace.c:136
       __register_pernet_operations net/core/net_namespace.c:1214 [inline]
       register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283
       register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370
       rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735
       do_one_initcall+0x238/0x830 init/main.c:1236
       do_initcall_level+0x157/0x210 init/main.c:1298
       do_initcalls+0x3f/0x80 init/main.c:1314
       kernel_init_freeable+0x42f/0x5d0 init/main.c:1551
       kernel_init+0x1d/0x2a0 init/main.c:1441
       ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
       ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242

       -> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:
       check_prev_add kernel/locking/lockdep.c:3134 [inline]
       check_prevs_add kernel/locking/lockdep.c:3253 [inline]
       validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869
       __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137
       lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
       lock_sock_fast include/net/sock.h:1723 [inline]
       subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28
       tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]
       tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137
       inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345
       inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061
       __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263
       inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371
       netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264
       __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370
       netlink_dump_start include/linux/netlink.h:338 [inline]
       inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405
       sock_diag_rcv_msg+0xe7/0x410
       netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
       sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280
       netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
       netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
       netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
       sock_sendmsg_nosec net/socket.c:730 [inline]
       __sock_sendmsg+0x221/0x270 net/socket.c:745
       ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
       ___sys_sendmsg net/socket.c:2638 [inline]
       __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
       do_syscall_64+0xf9/0x240
       entry_SYSCALL_64_after_hwframe+0x6f/0x77

    As noted by Eric we can break the lock dependency chain avoid
    dumping any extended info for the mptcp subflow listener:
    nothing actually useful is presented there.

    Fixes: b8adb69a7d29 ("mptcp: fix lockless access in subflow ULP diag")
    Cc: stable@vger.kernel.org
    Reported-by: Eric Dumazet <edumazet@google.com>
    Closes: https://lore.kernel.org/netdev/CANn89iJ=Oecw6OZDwmSYc9HJKQ_G32uN11L+oUcMu+TOD5Xiaw@mail.gmail.com/
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240223-upstream-net-20240223-misc-fixes-v1-9-162e87e48497@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Davide Caratti <dcaratti@redhat.com>
 2024-04-18 17:25:35 +02:00
Davide Caratti 574bf2a8a0 mptcp: fix data races on local_id 
JIRA: https://issues.redhat.com/browse/RHEL-32669
Upstream Status: net.git commit a7cfe776637004a4c938fde78be4bd608c32c3ef

commit a7cfe776637004a4c938fde78be4bd608c32c3ef
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 19:25:31 2024 +0100

    mptcp: fix data races on local_id

    The local address id is accessed lockless by the NL PM, add
    all the required ONCE annotation. There is a caveat: the local
    id can be initialized late in the subflow life-cycle, and its
    validity is controlled by the local_id_valid flag.

    Remove such flag and encode the validity in the local_id field
    itself with negative value before initialization. That allows
    accessing the field consistently with a single read operation.

    Fixes: 0ee4261a36 ("mptcp: implement mptcp_pm_remove_subflow")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Davide Caratti <dcaratti@redhat.com>
 2024-04-18 17:25:35 +02:00
Davide Caratti d9c18bd98a mptcp: fix lockless access in subflow ULP diag 
JIRA: https://issues.redhat.com/browse/RHEL-32669
Upstream Status: net.git commit b8adb69a7d29c2d33eb327bca66476fb6066516b

commit b8adb69a7d29c2d33eb327bca66476fb6066516b
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 19:25:30 2024 +0100

    mptcp: fix lockless access in subflow ULP diag

    Since the introduction of the subflow ULP diag interface, the
    dump callback accessed all the subflow data with lockless.

    We need either to annotate all the read and write operation accordingly,
    or acquire the subflow socket lock. Let's do latter, even if slower, to
    avoid a diffstat havoc.

    Fixes: 5147dfb508 ("mptcp: allow dumping subflow context to userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Davide Caratti <dcaratti@redhat.com>
 2024-04-18 17:25:35 +02:00
Davide Caratti 5147dfb508 mptcp: allow dumping subflow context to userspace 
add ulp-specific diagnostic functions, so that subflow information can be
dumped to userspace programs like 'ss'.

v2 -> v3:
- uapi: use bit macros appropriate for userspace

Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
 2020-03-29 22:14:48 -07:00