netdev - Crash when receiving FIN-ACK in TCP_FIN

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]

Date:   Sun, 20 Oct 2019 14:25:49 -0600
From:   Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
To:     netdev@...r.kernel.org, ycheng@...gle.com, eric.dumazet@...il.com,
        ncardwell@...gle.com
Subject: Crash when receiving FIN-ACK in TCP_FIN_WAIT1 state

We are seeing a crash in the TCP ACK codepath often in our regression
racks with an ARM64 device with 4.19 based kernel.

It appears that the tp->highest_ack is invalid when being accessed when 
a
FIN-ACK is received. In all the instances of the crash, the tcp socket
is in TCP_FIN_WAIT1 state.

[include/net/tcp.h]
static inline u32 tcp_highest_sack_seq(struct tcp_sock *tp)
{
	if (!tp->sacked_out)
		return tp->snd_una;

	if (tp->highest_sack == NULL)
		return tp->snd_nxt;

	return TCP_SKB_CB(tp->highest_sack)->seq;
}

[net/ipv4/tcp_input.c]
static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
{
...
	prior_fack = tcp_is_sack(tp) ? tcp_highest_sack_seq(tp) : tp->snd_una;


Crash call stack below-

  16496.596106:   <6> Unable to handle kernel paging request at virtual 
address fffffff2cd81a368
  16496.730771:   <2> pc : tcp_ack+0x174/0x11e8
  16496.734536:   <2> lr : tcp_rcv_state_process+0x318/0x1300
  16497.183109:   <2> Call trace:
  16497.183114:   <2>  tcp_ack+0x174/0x11e8
  16497.183115:   <2>  tcp_rcv_state_process+0x318/0x1300
  16497.183117:   <2>  tcp_v4_do_rcv+0x1a8/0x1f0
  16497.183118:   <2>  tcp_v4_rcv+0xe90/0xec8
  16497.183120:   <2>  ip_protocol_deliver_rcu+0x150/0x298
  16497.183121:   <2>  ip_local_deliver+0x21c/0x2a8
  16497.183122:   <2>  ip_rcv+0x1c4/0x210
  16497.183124:   <2>  __netif_receive_skb_core+0xab0/0xd90
  16497.183125:   <2>  netif_receive_skb_internal+0x12c/0x368
  16497.183126:   <2>  napi_gro_receive+0x1e0/0x290

Is it expected for the tp->highest_ack to be
accessed in this state?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project