lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <061d068ccd6f4db899d095cd61f52114@huawei.com>
Date:   Sat, 24 Sep 2022 07:59:15 +0000
From:   "liujian (CE)" <liujian56@...wei.com>
To:     John Fastabend <john.fastabend@...il.com>,
        Jakub Sitnicki <jakub@...udflare.com>,
        Eric Dumazet <edumazet@...gle.com>,
        davem <davem@...emloft.net>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
CC:     netdev <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: [bug report] one possible out-of-order issue in sockmap

Hello,

I had a scp failure problem here. I analyze the code, and the reasons may be as follows:

>From commit e7a5f1f1cd00 ("bpf/sockmap: Read psock ingress_msg before
 sk_receive_queue", if we use sockops (BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB
and BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) to enable socket's sockmap
function, and don't enable strparse and verdict function, the out-of-order
problem may occur in the following process.

client SK                                   server SK
--------------------------------------------------------------------------
tcp_rcv_synsent_state_process
  tcp_finish_connect
    tcp_init_transfer
      tcp_set_state(sk, TCP_ESTABLISHED);
      // insert SK to sockmap
    wake up waitter
    tcp_send_ack

tcp_bpf_sendmsg(msgA)
// msgA will go tcp stack
                                            tcp_rcv_state_process
                                              tcp_init_transfer
                                                //insert SK to sockmap
                                              tcp_set_state(sk,
                                                     TCP_ESTABLISHED)
                                              wake up waitter
tcp_bpf_sendmsg(msgB)
// msgB go sockmap
                                              tcp_bpf_recvmsg
                                                //msgB, out-of-order
                                              tcp_bpf_recvmsg
                                                //msgA, out-of-order


Even if msgA arrives earlier than msgB (in most cases), tcp_bpf_recvmsg receives msg from the psock queue first.
The worst case is that msgA waits for serverSK to change to TCP_ESTABLISHED in the protocol stack. msgA may arrive at the serverSK receive queue later than msgB.
If msgA befor than msgB, 

If the ACK packets of the three-way TCP handshake are dropped for a period of time, the OOO problem is easily reproduced.

iptables -A INPUT -p tcp -m tcp --dport 5006 --tcp-flags SYN,RST,ACK,FIN ACK -j DROP
...
iptables -D INPUT -p tcp -m tcp --dport 5006 --tcp-flags SYN,RST,ACK,FIN ACK -j DROP

Best Wishes
Liu Jian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ