netdev - Re: [NFS] [Bugme-new] [Bug 8891] New: in-kernel rpc generates broken RPCBPROC

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

Date:	Wed, 15 Aug 2007 15:57:15 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	netdev@...r.kernel.org, nfs@...ts.sourceforge.net,
	"bugme-daemon@...zilla.kernel.org" <bugme-daemon@...zilla.kernel.org>,
	speidel@...erschuss.de
Subject: Re: [NFS] [Bugme-new] [Bug 8891] New: in-kernel rpc generates broken
 RPCBPROC_GETVERSADDR v4 requests

Andrew Morton wrote:
> On Wed, 15 Aug 2007 12:22:51 -0700 (PDT)
> bugme-daemon@...zilla.kernel.org wrote:
> 
>> http://bugzilla.kernel.org/show_bug.cgi?id=8891
>>
>>            Summary: in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4
>>                     requests
>>            Product: Networking
>>            Version: 2.5
>>      KernelVersion: 2.6.22.1
>>           Platform: All
>>         OS/Version: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: normal
>>           Priority: P1
>>          Component: Other
>>         AssignedTo: acme@...stprotocols.net
>>         ReportedBy: speidel@...erschuss.de
>>
>>
>> Most recent kernel where this bug did not occur: 2.6.20
> 
> Apparently a regression.

RPCBIND v4 requests are an experimental feature.  They can be disabled 
via a kernel build option (CONFIG_SUNRPC_BIND34).  I think these are 
left enabled in Fedora to find just the type of problem before v3 and v4 
becomes the default.

>> Distribution: Fedora Core 6
>> Hardware Environment: x86_64
>> Software Environment: NFS
>> Problem Description: When locking a file, an invalid RPCBPROC_GETVERSADDR
>> procedure call is sent out
>>
>> Steps to reproduce:
>> on the NFS server, run: tcpdump -xX -pni eth0 -s0 port 111 and src host
>> theNFSclient
>> on a client running 2.6.22.1, run: flock -x /nfsmount/somefile ls
>> tcpdump will show:
>>
>> 17:10:01.290655 IP 141.2.15.141.34572 > 141.2.1.1.sunrpc: P 0:168(168) ack 1
>> win 183 <nop,nop,timestamp 966695 115079499>
>>         0x0000:  4500 00dc 53ad 4000 3f06 bcdc 8d02 0f8d  E...S.@.........
>>                 0x0010:  8d02 0101 870c 006f cdcd 938d db00 c8a7 
>> .......o........
>>         0x0020:  8018 00b7 e59d 0000 0101 080a 000e c027  ...............'
>>         0x0030:  06db f94b 8000 00a4 fd48 2a07 0000 0000  ...K.....H*.....
>>         0x0040:  0000 0002 0001 86a0 0000 0004 0000 0009  ................
>>         0x0050:  0000 0001 0000 0054 0000 03c6 0000 0007  .......T........
>>         0x0060:  6572 6964 796b 6500 0000 0000 0000 0000  eridyke.........
>>         0x0070:  0000 000e 0000 0000 0000 0001 0000 0002  ................
>>         0x0080:  0000 0003 0000 0004 0000 0005 0000 0006  ................
>>         0x0090:  0000 0007 0000 0007 0000 0009 0000 000a  ................
>>         0x00a0:  0000 000c 0000 0014 0000 001c 0000 0000  ................
>>         0x00b0:  0000 0000 0001 86b5 0000 0004 0000 0003  ................
>>         0x00c0:  7463 7000 0000 0009 3134 312e 322e 312e  tcp.....141.2.1.
>>         0x00d0:  3100 0000 0000 0004 7270 6362            1.......rpcb
>>
>> Note the "141.2.1.1" in the output.
>>
>> According to RFC 1833, you can read here the following fields:
>>
>> RPCBPROC_GETVERSADDR version 4 procedure is being called
>> r_prog == 0x000186b5 == 100021 == nfs.lockd
>> r_vers == 4
>> r_netid == (length 3) "tcp"
>> r_addr == (length 9) "141.2.1.1"
>> r_owner == (length 4) "rpcb"
>>
>> This r_addr member is supposed to contain an universal address. Although I have
>> no source for that, the RFC clearly says a service can listen to an address,
>> and RPCBPROC_GETVERSADDR is supposed to return an universal address too. From
>> this I can conclude that an universal address is supposed to contain the port
>> number, and other operating systems are using the format
>> a.b.c.d.PortHighByte.PortLowByte (like in FTP, but with . instead of ,). I
>> interpret the RFC 1833 so that the port number of the rpcbind, that is, 111, is
>> to be appended, so the correct value of r_addr would be "141.2.1.1.0.111". This
>> matches other implementations.

That RFC is unclear on exactly what a universal address should look 
like.  However speidel's interpretation is not unreasonable, and I'm 
glad he was able to check this against other implementations that I 
don't have.  My unit testing against Solaris did not reveal this issue.

I'll look into the problem.

View attachment "chuck.lever.vcf" of type "text/x-vcard" (291 bytes)