aboutsummaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2010-11-16 16:55:19 +1100
committerJ. Bruce Fields <bfields@redhat.com>2010-12-07 20:39:55 -0500
commited2849d3ecfa339435818eeff28f6c3424300cec (patch)
tree2fbef743779156c2c96afecd8311ff8488a90121 /fs
parentcf7d7e5a1980d1116ee152d25dac382b112b9c17 (diff)
downloadkernel_samsung_smdk4412-ed2849d3ecfa339435818eeff28f6c3424300cec.tar.gz
kernel_samsung_smdk4412-ed2849d3ecfa339435818eeff28f6c3424300cec.tar.bz2
kernel_samsung_smdk4412-ed2849d3ecfa339435818eeff28f6c3424300cec.zip
sunrpc: prevent use-after-free on clearing XPT_BUSY
When an xprt is created, it has a refcount of 1, and XPT_BUSY is set. The refcount is *not* owned by the thread that created the xprt (as is clear from the fact that creators never put the reference). Rather, it is owned by the absence of XPT_DEAD. Once XPT_DEAD is set, (And XPT_BUSY is clear) that initial reference is dropped and the xprt can be freed. So when a creator clears XPT_BUSY it is dropping its only reference and so must not touch the xprt again. However svc_recv, after calling ->xpo_accept (and so getting an XPT_BUSY reference on a new xprt), calls svc_xprt_recieved. This clears XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference. This is dangerous and has been seen to leave svc_xprt_enqueue working with an xprt containing garbage. So we need to hold an extra counted reference over that call to svc_xprt_received. For safety, any time we clear XPT_BUSY and then use the xprt again, we first get a reference, and the put it again afterwards. Note that svc_close_all does not need this extra protection as there are no threads running, and the final free can only be called asynchronously from such a thread. Signed-off-by: NeilBrown <neilb@suse.de> Cc: stable@kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions