Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Florian Weimer <fweimer@redhat.com>
To:     Steve Dickson <steved@redhat.com>
Cc:     Dai Ngo <dai.ngo@oracle.com>, linux-nfs@vger.kernel.org,
        libtirpc-devel@lists.sourceforge.net
Subject: Re: [Libtirpc-devel] [PATCH 1/1] Fix DoS vulnerability in statd and
 mountd
References: <20210807170248.68817-1-dai.ngo@oracle.com>
        <5d67875a-05bc-df80-3971-e8bde9b588b8@redhat.com>
Date:   Mon, 23 Aug 2021 11:37:04 +0200
In-Reply-To: <5d67875a-05bc-df80-3971-e8bde9b588b8@redhat.com> (Steve
        Dickson's message of "Sun, 8 Aug 2021 12:56:48 -0400")
Message-ID: <8735r0sdrz.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* Steve Dickson:

> Hello,
>
> On 8/7/21 1:02 PM, Dai Ngo wrote:
>> Currently my_svc_run does not handle poll time allowing idle TCP
>> connections to remain ESTABLISHED indefinitely. When the number
>> of connections reaches the limit the open file descriptors
>> (ulimit -n) then accept(2) fails with EMFILE. Since libtirpc does
>> not handle EMFILE returned from accept(2) this get my_svc_run into
>> a tight loop calling accept(2) resulting in the RPC service being
>> down, it's no longer able to service any requests.
>> Fix by removing idle connections when select(2) times out in
>> my_svc_run
>> and when open(2) returns EMFILE/ENFILE in auth_reload.
>> Signed-off-by: dai.ngo@oracle.com
>> ---
>>   support/export/auth.c  | 12 ++++++++++--
>>   utils/mountd/svc_run.c | 10 ++++++++--
>>   utils/statd/svc_run.c  | 11 ++++++++---
>>   3 files changed, 26 insertions(+), 7 deletions(-)
>> diff --git a/support/export/auth.c b/support/export/auth.c
>> index 03ce4b8a0e1e..0bb189fb4037 100644
>> --- a/support/export/auth.c
>> +++ b/support/export/auth.c
>> @@ -81,6 +81,8 @@ check_useipaddr(void)
>>   		cache_flush();
>>   }
>>   +extern void __svc_destroy_idle(int, bool_t);

> This is adding to the API... Which means mountd
> and statd (the next patch) will not compile without
> this new API...
>
> Does this mean an SONAME change? That is such a pain!

Do you symbol versioning?  For RPM-based distributions, adding the new
symbol under a new symbol version would avoid the need for a SONAME
change.

Debian-based distributions use explicit symbol list files and are more
flexible.

Thanks,
Florian