summaryrefslogtreecommitdiffstats
path: root/Documentation/pti
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2017-10-09 14:14:51 +0200
committerDavid S. Miller <davem@davemloft.net>2017-10-09 10:27:49 -0700
commit41c87425a1ac9b633e0fcc78eb1f19640c8fb5a0 (patch)
treec91239da85b6dabccc4c3be54bafa71d181de790 /Documentation/pti
parent6df4d17c442f39137026bce387b0100eef8a25ba (diff)
downloadlinux-41c87425a1ac9b633e0fcc78eb1f19640c8fb5a0.tar.gz
linux-41c87425a1ac9b633e0fcc78eb1f19640c8fb5a0.tar.bz2
linux-41c87425a1ac9b633e0fcc78eb1f19640c8fb5a0.zip
netlink: do not set cb_running if dump's start() errs
It turns out that multiple places can call netlink_dump(), which means it's still possible to dereference partially initialized values in dump() that were the result of a faulty returned start(). This fixes the issue by calling start() _before_ setting cb_running to true, so that there's no chance at all of hitting the dump() function through any indirect paths. It also moves the call to start() to be when the mutex is held. This has the nice side effect of serializing invocations to start(), which is likely desirable anyway. It also prevents any possible other races that might come out of this logic. In testing this with several different pieces of tricky code to trigger these issues, this commit fixes all avenues that I'm aware of. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/pti')
0 files changed, 0 insertions, 0 deletions