Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

net: synack packets can be attached to request sockets

selinux needs few changes to accommodate fact that SYNACK messages
can be attached to a request socket, lacking sk_security pointer

(Only syncookies are still attached to a TCP_LISTEN socket)

Adds a new sk_listener() helper, and use it in selinux and sch_fq

Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported by: kernel test robot <ying.huang@linux.intel.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@parisplace.org>
Acked-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

authored by

Eric Dumazet and committed by
David S. Miller
e446f9df 21d11bd6

+18 -5
+8
include/net/sock.h
··· 2201 2201 return (1 << sk->sk_state) & ~(TCPF_TIME_WAIT | TCPF_NEW_SYN_RECV); 2202 2202 } 2203 2203 2204 + /* This helper checks if a socket is a LISTEN or NEW_SYN_RECV 2205 + * SYNACK messages can be attached to either ones (depending on SYNCOOKIE) 2206 + */ 2207 + static inline bool sk_listener(const struct sock *sk) 2208 + { 2209 + return (1 << sk->sk_state) & (TCPF_LISTEN | TCPF_NEW_SYN_RECV); 2210 + } 2211 + 2204 2212 void sock_enable_timestamp(struct sock *sk, int flag); 2205 2213 int sock_get_timestamp(struct sock *, struct timeval __user *); 2206 2214 int sock_get_timestampns(struct sock *, struct timespec __user *);
+2 -1
net/sched/sch_fq.c
··· 225 225 return &q->internal; 226 226 227 227 /* SYNACK messages are attached to a TCP_NEW_SYN_RECV request socket 228 + * or a listener (SYNCOOKIE mode) 228 229 * 1) request sockets are not full blown, 229 230 * they do not contain sk_pacing_rate 230 231 * 2) They are not part of a 'flow' yet ··· 233 232 * especially if the listener set SO_MAX_PACING_RATE 234 233 * 4) We pretend they are orphaned 235 234 */ 236 - if (!sk || sk->sk_state == TCP_NEW_SYN_RECV) { 235 + if (!sk || sk_listener(sk)) { 237 236 unsigned long hash = skb_get_hash(skb) & q->orphan_mask; 238 237 239 238 /* By forcing low order bit to 1, we make sure to not
+8 -4
security/selinux/hooks.c
··· 4898 4898 if (sk) { 4899 4899 struct sk_security_struct *sksec; 4900 4900 4901 - if (sk->sk_state == TCP_LISTEN) 4901 + if (sk_listener(sk)) 4902 4902 /* if the socket is the listening state then this 4903 4903 * packet is a SYN-ACK packet which means it needs to 4904 4904 * be labeled based on the connection/request_sock and ··· 5005 5005 * unfortunately, this means more work, but it is only once per 5006 5006 * connection. */ 5007 5007 if (skb_dst(skb) != NULL && skb_dst(skb)->xfrm != NULL && 5008 - !(sk != NULL && sk->sk_state == TCP_LISTEN)) 5008 + !(sk && sk_listener(sk))) 5009 5009 return NF_ACCEPT; 5010 5010 #endif 5011 5011 ··· 5022 5022 secmark_perm = PACKET__SEND; 5023 5023 peer_sid = SECINITSID_KERNEL; 5024 5024 } 5025 - } else if (sk->sk_state == TCP_LISTEN) { 5025 + } else if (sk_listener(sk)) { 5026 5026 /* Locally generated packet but the associated socket is in the 5027 5027 * listening state which means this is a SYN-ACK packet. In 5028 5028 * this particular case the correct security label is assigned ··· 5033 5033 * selinux_inet_conn_request(). See also selinux_ip_output() 5034 5034 * for similar problems. */ 5035 5035 u32 skb_sid; 5036 - struct sk_security_struct *sksec = sk->sk_security; 5036 + struct sk_security_struct *sksec; 5037 + 5038 + if (sk->sk_state == TCP_NEW_SYN_RECV) 5039 + sk = inet_reqsk(sk)->rsk_listener; 5040 + sksec = sk->sk_security; 5037 5041 if (selinux_skb_peerlbl_sid(skb, family, &skb_sid)) 5038 5042 return NF_DROP; 5039 5043 /* At this point, if the returned skb peerlbl is SECSID_NULL