netdev - [PATCH v2] 9p/client: don't assume signal_pending() clears on recalc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <9422b998-5bab-85cc-5416-3bb5cf6dd853@kernel.dk>
Date:   Fri, 3 Feb 2023 09:04:28 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     netdev <netdev@...r.kernel.org>, Jakub Kicinski <kuba@...nel.org>
Cc:     Pengfei Xu <pengfei.xu@...el.com>
Subject: [PATCH v2] 9p/client: don't assume signal_pending() clears on
 recalc_sigpending()

signal_pending() really means that an exit to userspace is required to
clear the condition, as it could be either an actual signal, or it could
be TWA_SIGNAL based task_work that needs processing. The 9p client
does a recalc_sigpending() to take care of the former, but that still
leaves TWA_SIGNAL task_work. The result is that if we do have TWA_SIGNAL
task_work pending, then we'll sit in a tight loop spinning as
signal_pending() remains true even after recalc_sigpending().

Move the signal_pending() logic into a helper that deals with both, and
return -ERESTARTSYS if the reason for signal_pendding() being true is
that we have task_work to process.

Link: https://lore.kernel.org/lkml/Y9TgUupO5C39V%2FDW@xpf.sh.intel.com/
Reported-and-tested-by: Pengfei Xu <pengfei.xu@...el.com>
Signed-off-by: Jens Axboe <axboe@...nel.dk>

---

v2: don't rely on task_work_run(), rather just punt with -ERESTARTYS at
    that point. For one, we don't want to export task_work_run(), it's
    in-kernel only. And secondly, we need to ensure we have a sane state
    before running task_work. The latter did look fine before, but this
    should be saner. Tested this also fixes the report as well for me.

diff --git a/net/9p/client.c b/net/9p/client.c
index 622ec6a586ee..9caa66cbd5b7 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -652,6 +652,25 @@ static struct p9_req_t *p9_client_prepare_req(struct p9_client *c,
 	return ERR_PTR(err);
 }
 
+static int p9_sigpending(int *sigpending)
+{
+	*sigpending = 0;
+
+	if (!signal_pending(current))
+		return 0;
+
+	/*
+	 * If we have a TIF_NOTIFY_SIGNAL pending, abort to get it
+	 * processed.
+	 */
+	if (test_thread_flag(TIF_NOTIFY_SIGNAL))
+		return -ERESTARTSYS;
+
+	*sigpending = 1;
+	clear_thread_flag(TIF_SIGPENDING);
+	return 0;
+}
+
 /**
  * p9_client_rpc - issue a request and wait for a response
  * @c: client session
@@ -687,12 +706,9 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...)
 	req->tc.zc = false;
 	req->rc.zc = false;
 
-	if (signal_pending(current)) {
-		sigpending = 1;
-		clear_thread_flag(TIF_SIGPENDING);
-	} else {
-		sigpending = 0;
-	}
+	err = p9_sigpending(&sigpending);
+	if (err)
+		goto reterr;
 
 	err = c->trans_mod->request(c, req);
 	if (err < 0) {
@@ -789,12 +805,9 @@ static struct p9_req_t *p9_client_zc_rpc(struct p9_client *c, int8_t type,
 	req->tc.zc = true;
 	req->rc.zc = true;
 
-	if (signal_pending(current)) {
-		sigpending = 1;
-		clear_thread_flag(TIF_SIGPENDING);
-	} else {
-		sigpending = 0;
-	}
+	err = p9_sigpending(&sigpending);
+	if (err)
+		goto reterr;
 
 	err = c->trans_mod->zc_request(c, req, uidata, uodata,
 				       inlen, olen, in_hdrlen);

-- 
Jens Axboe