svcrpc: fix list-corrupting race on nfsd shutdown

After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd: split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no longer removed its xpt_ready (then sk_ready) field from whatever list it was on, noting that there was no point since the whole list was about to be destroyed anyway. That was mostly true, but forgot that a few svc_xprt_enqueue()'s might still be hanging around playing with the about-to-be-destroyed list, and could get themselves into trouble writing to freed memory if we left this xprt on the list after freeing it. (This is actually functionally identical to a patch made first by Ben Greear, but with more comments.) Cc: stable@kernel.org Cc: gnb@fmeh.org Reported-by: Ben Greear <greearb@candelatech.com> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>

svcrpc: fix list-corrupting race on nfsd shutdown
After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd: split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no longer removed its xpt_ready (then sk_ready) field from whatever list it was on, noting that there was no point since the whole list was about to be destroyed anyway. That was mostly true, but forgot that a few svc_xprt_enqueue()'s might still be hanging around playing with the about-to-be-destroyed list, and could get themselves into trouble writing to freed memory if we left this xprt on the list after freeing it. (This is actually functionally identical to a patch made first by Ben Greear, but with more comments.) Cc: stable@kernel.org Cc: gnb@fmeh.org Reported-by: Ben Greear <greearb@candelatech.com> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
J. Bruce Fields
1 parent 058c5c9999
Showing 1 changed file with 6 additions and 5 deletions Side-by-side Diff
net/sunrpc/svc_xprt.c
@@ -902,12 +902,13 @@
 	if (!test_and_set_bit(XPT_DETACHED, &xprt->xpt_flags))
 		list_del_init(&xprt->xpt_list);
 	/*
-	 * We used to delete the transport from whichever list
-	 * it's sk_xprt.xpt_ready node was on, but we don't actually
-	 * need to.  This is because the only time we're called
-	 * while still attached to a queue, the queue itself
-	 * is about to be destroyed (in svc_destroy).
+	 * The only time we're called while xpt_ready is still on a list
+	 * is while the list itself is about to be destroyed (in
+	 * svc_destroy).  BUT svc_xprt_enqueue could still be attempting
+	 * to add new entries to the sp_sockets list, so we can't leave
+	 * a freed xprt on it.
 	 */
+	list_del_init(&xprt->xpt_ready);
 	if (test_bit(XPT_TEMP, &xprt->xpt_flags))
 		serv->sv_tmpcnt--;
 	spin_unlock_bh(&serv->sv_lock);
...	...	@@ -902,12 +902,13 @@
902	902	if (!test_and_set_bit(XPT_DETACHED, &xprt->xpt_flags))
903	903	list_del_init(&xprt->xpt_list);
904	904	/*
905		- * We used to delete the transport from whichever list
906		- * it's sk_xprt.xpt_ready node was on, but we don't actually
907		- * need to. This is because the only time we're called
908		- * while still attached to a queue, the queue itself
909		- * is about to be destroyed (in svc_destroy).
	905	+ * The only time we're called while xpt_ready is still on a list
	906	+ * is while the list itself is about to be destroyed (in
	907	+ * svc_destroy). BUT svc_xprt_enqueue could still be attempting
	908	+ * to add new entries to the sp_sockets list, so we can't leave
	909	+ * a freed xprt on it.
910	910	*/
	911	+ list_del_init(&xprt->xpt_ready);
911	912	if (test_bit(XPT_TEMP, &xprt->xpt_flags))
912	913	serv->sv_tmpcnt--;
913	914	spin_unlock_bh(&serv->sv_lock);