[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FE5BFAB-1988-4CA9-9B97-CEF73396B4EC@purdue.edu>
Date: Tue, 13 Apr 2021 20:51:22 +0000
From: "Gong, Sishuai" <sishuai@...due.edu>
To: "xie.he.0141@...il.com" <xie.he.0141@...il.com>,
"eyal.birger@...il.com" <eyal.birger@...il.com>,
"yonatanlinik@...il.com" <yonatanlinik@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: A data race between fanout_demux_rollover() and __fanout_unlink()
Hi,
We found a data race in linux-5.12-rc3 between af_packet.c functions fanout_demux_rollover() and __fanout_unlink() and we are able to reproduce it under x86.
When the two functions are running together, __fanout_unlink() will grab a lock and modify some attribute of packet_fanout variable, but fanout_demux_rollover() may or may not see this update depending on different interleavings, as shown in below.
Currently, we didn’t find any explicit errors due to this data race. But in fanout_demux_rollover(), we noticed that the data-racing variable is involved in the later operation, which might be a concern.
------------------------------------------
Execution interleaving
Thread 1 Thread 2
__fanout_unlink() fanout_demux_rollover()
spin_lock(&f->lock);
po = pkt_sk(f->arr[idx]);
// po is a out-of-date value
f->arr[i] = f->arr[f->num_members - 1];
spin_unlock(&f->lock);
Thanks,
Sishuai
Powered by blists - more mailing lists