NetBSD Problem Report #56532

From www@netbsd.org  Wed Dec  1 21:47:43 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7448C1A921F
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  1 Dec 2021 21:47:43 +0000 (UTC)
Message-Id: <20211201214741.C5E291A9239@mollari.NetBSD.org>
Date: Wed,  1 Dec 2021 21:47:41 +0000 (UTC)
From: anthony.mallet@laas.fr
Reply-To: anthony.mallet@laas.fr
To: gnats-bugs@NetBSD.org
Subject: RPC client unconditionally unblock user signals
X-Send-Pr-Version: www-1.0

>Number:         56532
>Category:       lib
>Synopsis:       RPC client unconditionally unblock user signals
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 01 21:50:00 +0000 2021
>Originator:     Anthony Mallet
>Release:        -current
>Organization:
>Environment:
NetBSD ficus 9.99.91 NetBSD 9.99.91 (FICUS) #31: Sat Oct 16 15:04:36 CEST 2021  troot@ficus:/usr/obj/sys/arch/amd64/compile/FICUS amd64

>Description:
RPC client functions unconditionally unblock SIGINT, SIGTERM and SIGQUIT
and others for a small amount of time. This happens for instance in clnt_vc_call()
https://anonhg.netbsd.org/src/file/tip/lib/libc/rpc/clnt_vc.c#l224

This was introduced in rev. 1.23 of clnt_vc.c
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/rpc/clnt_vc.c.diff?r1=1.22&r2=1.23
and rev. 1.29 of clnt.dg.c
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/rpc/clnt_dg.c.diff?r1=1.28&r2=1.29

It happens that I have a program that blocks those signals in all threads and uses a dedicated thread to handle the signals with sigwait(2).
In this context, a thread using RPC calls will wrongly unblock the signals and this leaves a small time window where the signal will be received by a thread not prepared to deal with it.

I think that the thr_sigsetmask function should be called with SIG_BLOCK instead of SIG_SETMASK to not alter the existing mask. The attached patch shows an example for clnt_vc_destroy(). I can provide a complete patch if you agree with this change.

>How-To-Repeat:

>Fix:
Index: clnt_vc.c
===================================================================
RCS file: /cvsroot/src/lib/libc/rpc/clnt_vc.c,v
retrieving revision 1.27
diff -u -r1.27 clnt_vc.c
--- clnt_vc.c   21 Aug 2021 23:00:30 -0000      1.27
+++ clnt_vc.c   1 Dec 2021 21:46:12 -0000
@@ -664,7 +664,7 @@
        ct = (struct ct_data *) cl->cl_private;

        __clnt_sigfillset(&newmask);
-       thr_sigsetmask(SIG_SETMASK, &newmask, &mask);
+       thr_sigsetmask(SIG_BLOCK, &newmask, &mask);
        mutex_lock(&clnt_fd_lock);
 #ifdef _REENTRANT
        ct_fd = ct->ct_fd;

Home	PR Database Search