From: Steve Dickson <SteveD@redhat.com>
To: bstroesser@ts.fujitsu.com, neilb@suse.de, linux-nfs@vger.kernel.org
Cc: bfields@fieldses.org
Subject: Re: [nfs-utils] [PATCH 0/3] rpc.mountd: fix some vulnerabilities
Date: Tue, 11 Nov 2014 13:24:31 -0500 [thread overview]
Message-ID: <5462545F.4010706@RedHat.com> (raw)
In-Reply-To: <d6437a$6ag11f@dgate10u.abg.fsc.net>
Hello,
On 11/05/2014 03:21 PM, bstroesser@ts.fujitsu.com wrote:
> Hello,
>
> I'm sending a small set of 3 patches for a problem, that I have
> reported a few weeks ago.
> rpc.mountd can be blocked by a bad client, that sends lots of
> RPC requests, but never reads the replies from the socket either
> intentionally or e.g. caused by a wrong configured MTU.
>
> While looking for a possible solution, I found another weakness
> in rpc.mountd if it is used "multithreaded" (-t nn).
>
> The first two patches fix that weakness in the case of !HAVE_LIBTIRPC
> and HAVE_LIBTIRPC.
> The third patch more a kind of suggestion how the main problem could
> be fixed. I don't know whether we can set MAXREC without causing
> new troubles. When this patch is used, a further patch for libtirpc
> also should be used. You can find it here:
> http://sourceforge.net/p/libtirpc/mailman/libtirpc-devel/?viewmonth=201409
Over the weekend I took a good hard look at these 3 patches and
the one for libtirpc with the reproducer Bodo supplied me.
(Bodo, thanks all the help getting things set up!).
I agree with the libtirpc patch so its been committed,
but other three made me nervous so I wanted to take a
good hard look at them. (Neil's question, "do we really
what to make these non-block" haunted me ;-) ).
It turns out, at least in my setup, these patches do not
and can not stop the mountd DOS that Bodo's reproducer
creates.
Here is why they do not work:
The fd that the write() is getting hung on, is not be created
by the 3 nfs_svc_create() calls in mountd:main(). Its
being created by the accept() when the tcp connection
is created (via SVC_RECV()), so making those fds coming
out of the nfs_svc_create() non-blocking does nothing.
Here is the hang can't be stop (for now):
Here is the stack:
Stack trace of thread 4150:
#0 0x00000036816f0e90 write (libc.so.6)
#1 0x00007fd53837da6d write_vc (libtirpc.so.1)
#2 0x00007fd53838103f flush_out (libtirpc.so.1)
#3 0x00007fd53837dd81 svc_vc_reply (libtirpc.so.1)
#4 0x00007fd53837b096 svcerr_noprog (libtirpc.so.1)
#5 0x00007fd53837b360 svc_getreq_common (libtirpc.so.1)
#6 0x00000000004086d9 my_svc_getreqset (mountd)
#7 0x0000000000403d80 main (mountd)
#8 0x000000368161ffe0 __libc_start_main (libc.so.6)
#9 0x00000000004040f5 _start (mountd)
The fd that created by the SVC_RECV() is never
given back to the app (in case mountd) to make
it non-blocking. Its used in the error path
where it get hung up in the write(). The
app has no control over that.
Now I definitely see a problem, but these
patches (with the exception of the libtirpc
patch) don't address the problem I am seeing.
So unless I'm not seeing something, I'm not in
favor of taking these 3 patches.
thoughts?
steved.
next prev parent reply other threads:[~2014-11-11 18:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 20:21 [nfs-utils] [PATCH 0/3] rpc.mountd: fix some vulnerabilities bstroesser
2014-11-11 18:24 ` Steve Dickson [this message]
2014-11-11 19:01 ` Strösser, Bodo
2014-11-11 23:00 ` NeilBrown
2014-11-12 15:58 ` Steve Dickson
2014-11-12 18:57 ` Steve Dickson
2014-11-12 19:26 ` Strösser, Bodo
[not found] <61eb00$5dituo@dgate20u.abg.fsc.net>
2014-11-05 21:05 ` J. Bruce Fields
2014-11-05 21:25 ` Strösser, Bodo
[not found] ` <20141106084741.40980d12@notabene.brown>
2014-11-05 21:55 ` J. Bruce Fields
2014-11-06 15:00 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5462545F.4010706@RedHat.com \
--to=steved@redhat.com \
--cc=bfields@fieldses.org \
--cc=bstroesser@ts.fujitsu.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.