In RHEL 8 and later, SYN_RECV sockets are not created and "Possible SYN flooding" is not logged when the accept backlog is full.

Environment

• Red Hat Enterprise Linux 8 and later

Issue

In RHEL8 and later, the following behaviors are observed when the accept queue (defined by the backlog argument in listen()) is full:

• When the backlog is full, SYN_RECV sockets are not created, and SYN cookies are not sent.

• The message "Possible SYN flooding on port..." is not logged, even if net.ipv4.tcp_syncookies is set to 2.

Resolution

• When the accept backlog is full, the kernel now strictly drops incoming SYN packets before they can trigger SYN cookie generation or logging.

Relevant code snippet: net/ipv4/tcp_input.c (kernel-4.18.0-553.el8_10)

int tcp_conn_request(struct request_sock_ops *rsk_ops,
...
        } else {
                syncookies = READ_ONCE(net->ipv4.sysctl_tcp_syncookies);

                if (syncookies == 2 || inet_csk_reqsk_queue_is_full(sk)) {
                        want_cookie = tcp_syn_flood_action(sk,  //*1
                                                           rsk_ops->slab_name);
                        if (!want_cookie)
                                goto drop;
                }
        }

        if (sk_acceptq_is_full(sk)) {  //*2
                NET_INC_STATS(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
                goto drop;
        }

        req = inet_reqsk_alloc(rsk_ops, sk, !want_cookie);   //*3

...

*1: Calls tcp_syn_flood_action to determine if SYN cookies should be used.
*2: If the accept queue (sk_acceptq) is full, the packet is silently dropped after incrementing ListenOverflows. This check occurs before the request socket is created.
*3: The transmission of SYN/ACK (including SYN cookies) occurs only after this point.

static bool tcp_syn_flood_action(const struct sock *sk, const char *proto)

        if (!READ_ONCE(queue->synflood_warned) && syncookies != 2 &&    //*4
            xchg(&queue->synflood_warned, 1) == 0) {
                if (IS_ENABLED(CONFIG_IPV6) && sk->sk_family == AF_INET6) {
                        net_info_ratelimited("%s: Possible SYN flooding on port [%pI6c]:%u. %s.\n",
                                        proto, inet6_rcv_saddr(sk),
                                        sk->sk_num, msg);
                } else {
                        net_info_ratelimited("%s: Possible SYN flooding on port %pI4:%u. %s.\n",
                                        proto, &sk->sk_rcv_saddr,
                                        sk->sk_num, msg);
                }
        }

*4: As originally designed, the "Possible SYN flooding" message is not logged when net.ipv4.tcp_syncookies is set to 2.

• To verify if the backlog has reached its limit, please refer to Listening TCP server ignores SYN or ACK for new connection handshake

Root Cause

Disclaimer: Links contained herein to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

• This behavior was introduced by the following upstream change to prevent resource exhaustion when the accept queue is overflowed:
  Content from github.com is not included.tcp/dccp: drop SYN packets if accept queue is full

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.