Skip to contentSkip to conversation

New: in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4 requests

Bugme-new Andrew Morton 2 participants 2 messages Aug 15, 2007 1 message not in the archive

Subsystems (4)
Networking Network drivers NFS client NFS server
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author
#1 lore raw
Quoted 18 lines · On Wed, 15 Aug 2007 12:22:51 -0700 (PDT) [email protected] 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: [email protected]
        ReportedBy: [email protected]
Quoted 1 line

Most recent kernel where this bug did not occur: 2.6.20

Apparently a regression.

Quoted 66 lines

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.

Of course, all this does sound like nitpicking, and as the callee is not even supposed to look at the port number (this argument is only there so the callee can decide correctly which interface address to use for the response). However, this omission triggers an apparently unpatched denial of service vulnerability against HP-UX 11.11's rpcbind and causes it to quit with a core dump and a bus error. When using a correctly formed universal address, or the empty string, there is no crash of HP-UX's rpcbind.

And of course it is HP who has to fix the DoS bug - but Linux 2.6.22 triggers it by a RFC violation, which is a minor bug to be fixed on Linux's side. By the way, does anyone have the right contacts to HP to report this bug? I do not have a HP service contract any more, and the only other support place I found is their public forum, where I of course can only provide limited information about the bug (basically, the same I am posting here).

Quoted 6 lines

Maybe the bug is fixed in a more current kernel, I was only using Fedora's highly patched distribution kernel and compared it to the sources of the base version in the main tree, where I see the very same problem in the source code. So I do not think it was Fedora who caused the problem, and am assigning it to mainline.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

#2 lore raw
Quoted 21 lines · Andrew Morton
Quoted 18 lines · On Wed, 15 Aug 2007 12:22:51 -0700 (PDT) [email protected] 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: [email protected]
        ReportedBy: [email protected]
Quoted 3 lines
Quoted 1 line

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.

Quoted 41 lines
Quoted 41 lines

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"

Quoted 9 lines
Quoted 9 lines

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.

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs