netfilter: ctnetlink: fix incorrect nf_ct_put during hash resize
authorLiping Zhang <zlpnobody@gmail.com>
Sat, 20 May 2017 23:22:49 +0000 (07:22 +0800)
committerBen Hutchings <ben@decadent.org.uk>
Fri, 15 Sep 2017 17:30:48 +0000 (18:30 +0100)
commit559211ac7b05b3165cc572f936c1fb82bfdb1fc9
tree66cbd98f867e98e5bc998f69e597aa6e071e44af
parent2b7d467bc3a289da1fa8dffc1e20bc375fc1b5b7
netfilter: ctnetlink: fix incorrect nf_ct_put during hash resize

commit fefa92679dbe0c613e62b6c27235dcfbe9640ad1 upstream.

If nf_conntrack_htable_size was adjusted by the user during the ct
dump operation, we may invoke nf_ct_put twice for the same ct, i.e.
the "last" ct. This will cause the ct will be freed but still linked
in hash buckets.

It's very easy to reproduce the problem by the following commands:
  # while : ; do
  echo $RANDOM > /proc/sys/net/netfilter/nf_conntrack_buckets
  done
  # while : ; do
  conntrack -L
  done
  # iperf -s 127.0.0.1 &
  # iperf -c 127.0.0.1 -P 60 -t 36000

After a while, the system will hang like this:
  NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [bash:20184]
  NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [iperf:20382]
  ...

So at last if we find cb->args[1] is equal to "last", this means hash
resize happened, then we can set cb->args[1] to 0 to fix the above
issue.

Fixes: d205dc40798d ("[NETFILTER]: ctnetlink: fix deadlock in table dumping")
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
net/netfilter/nf_conntrack_netlink.c