linux-kernel - Re: [NFS] nfsd closes port 2049

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <18195.52347.544844.155538@notabene.brown>
Date:	Tue, 16 Oct 2007 06:24:27 +1000
From:	Neil Brown <neilb@...e.de>
To:	righiandr@...rs.sourceforge.net
Cc:	LKML <linux-kernel@...r.kernel.org>, nfs@...ts.sourceforge.net
Subject: Re: [NFS] nfsd closes port 2049

On Monday October 15, a.righi@...eca.it wrote:
> Hi all,
> 
> I'm trying to debug a weird problem with nfsd on a 2.6.16.27-0.6-smp
> kernel.
> 
> 1 server: SuSE SLES 10 x86_64, config attached
> 256 clients: RHEL4 Update 4 2.6.9-42.ELsmp x86_64
> 
> Using nfs v3.
> 
> The clients have been happily talking to the server for several days
> without incident.
> 
> The weird thing is that at a certain point the socket opened on port
> 2049 on the NFS server is being closed for unknown reasons (or better
> for unknown reasons for me!).

This is fixed in any release based on 2.6.16.31 or later.
The relevant mainline patch is 
    1a047060a99f274a7c52cfea8159e4142a14b8a7
as below.
So update your kernel package.

NeilBrown


commit 1a047060a99f274a7c52cfea8159e4142a14b8a7
Author: NeilBrown <neilb@...e.de>
Date:   Thu Oct 19 23:29:13 2006 -0700

    [PATCH] knfsd: fix race that can disable NFS server
    
    This patch is suitable for just about any 2.6 kernel.  It should go in
    2.6.19 and 2.6.18.2 and possible even the .17 and .16 stable series.
    
    This is a long standing bug that seems to have only recently become
    apparent, presumably due to increasing use of NFS over TCP - many
    distros seem to be making it the default.
    
    The SK_CONN bit gets set when a listening socket may be ready
    for an accept, just as SK_DATA is set when data may be available.
    
    It is entirely possible for svc_tcp_accept to be called with neither
    of these set.  It doesn't happen often but there is a small race in
    svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the
    spin_lock.  They could be cleared immediately after the test and
    before the lock is gained.
    
    This normally shouldn't be a problem.  The sockets are non-blocking so
    trying to read() or accept() when ther is nothing to do is not a problem.
    
    However: svc_tcp_recvfrom makes the decision "Should I accept() or
    should I read()" based on whether SK_CONN is set or not.  This usually
    works but is not safe.  The decision should be based on whether it is
    a TCP_LISTEN socket or a TCP_CONNECTED socket.
    
    Signed-off-by: Neil Brown <neilb@...e.de>
    Cc: Adrian Bunk <bunk@...sta.de>
    Cc: <stable@...nel.org>
    Cc: Trond Myklebust <trond.myklebust@....uio.no>
    Signed-off-by: Andrew Morton <akpm@...l.org>
    Signed-off-by: Linus Torvalds <torvalds@...l.org>

diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 61e307c..96521f1 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -973,7 +973,7 @@ svc_tcp_recvfrom(struct svc_rqst *rqstp)
 		return 0;
 	}
 
-	if (test_bit(SK_CONN, &svsk->sk_flags)) {
+	if (svsk->sk_sk->sk_state == TCP_LISTEN) {
 		svc_tcp_accept(svsk);
 		svc_sock_received(svsk);
 		return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/