Bug 709393 - (CVE-2011-2491) CVE-2011-2491 kernel: rpc task leak after flock()ing NFS share
CVE-2011-2491 kernel: rpc task leak after flock()ing NFS share
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
Unspecified Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
Norm Murray
: Security
Depends On: 709546 709547 709548 709549 709550 752999
  Show dependency treegraph
Reported: 2011-05-31 11:31 EDT by Vasily Averin
Modified: 2015-07-31 08:43 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-07-29 08:48:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output with NFS/NLM/RPC debug (208.82 KB, text/plain)
2011-05-31 11:31 EDT, Vasily Averin
no flags Details
patch for 2.6.39 kernel (1.42 KB, patch)
2011-05-31 11:36 EDT, Vasily Averin
no flags Details | Diff
Proposed patch from Trond (2.98 KB, patch)
2011-05-31 21:00 EDT, Eugene Teo (Security Response)
no flags Details | Diff

  None (edit)
Description Vasily Averin 2011-05-31 11:31:26 EDT
Created attachment 502027 [details]
dmesg output with NFS/NLM/RPC debug

btw. I'm reporting this issue to akpm@ and to Trond Myklebust because other vendors and upstream linux kernel is affected too.

Description of problem:
unprivileged user can use flock syscall for NFS share to trigger unlimited resource leak and this could cause node DoS.

flock on NFS calls nlmclnt_lock() function, where nlmclnt_call() executes synchronous RPC task NLMPROC_LOCK. Via several subcalls (call_bind) it successfully connects to NFS server and decodes its reply, however because server did not set up r_port rpcb_getport_done() returns -EACCES, and following rpc subcall call_bind_status() in this case repeats call_bind() after 3 sec timeout.

It isn't a big problem, and this cycle could be broken by signal, however error path of nlmclnt_lock() executes identical asynchronous RPC call to unlock taken lock. Waiting of result of this call is also canceled by signal, however in this case RPC call is asynchronous, it cycles too and never finished.

I would like to ask Trond to recheck my analyze and review my patch with fix of this issue or propose some better and more correct solution.

My idea is to break cycle described above, return -EOPNOTSUPP to nlmclnt_lock(), check it on error path and do not execute NLMPROC_UNLOCK call because we already know that server does not support locking operations.

PS. one more separate issue: NLMPROC_UNLOCK can be cycled in another place: nlmclnt_unlock_callback() restarts RPC task in case of any errors. Therefore we cannot execute NLMPROC_UNLOCK on error path in case of server errors. I did not reproduce this issue, however I believe it's possible.

PPS. Also I've found similar cycles in other nlm callbacks, however I have no ideas is it possible to exploit it. However I would like to ask Trond to review this code too.

Version-Release number of selected component (if applicable):
I've reproduced this issue on RHEL5, RHEL6, ubuntu 11.04 and upstream linux kernel 2.6.39. 

How reproducible:

Actual results:
flock hangs, can be canceled by signal, as result one more rpc task leaks
(FYI: sysctl -w sunrpc.rpc_debug=0 dumps status of active RPC taks) 

Expected results:
no hangs, no leaks

Additional info:
dmesg output with NFS/NLM/RPC debug and concept of patch are attached.
Because  vendor-sec is no longer in use I'm preparing private report to akpm@ and to Trond Myklebust, probably they can propose some better solution
Comment 1 Vasily Averin 2011-05-31 11:36:57 EDT
Created attachment 502030 [details]
patch for 2.6.39 kernel
Comment 3 Eugene Teo (Security Response) 2011-05-31 21:00:30 EDT
Created attachment 502142 [details]
Proposed patch from Trond

How about something like the appended fix? It should deal with errors
such as the rebind issue, but only after retrying a few times.

Comment 7 Eugene Teo (Security Response) 2011-05-31 21:12:53 EDT

Red Hat would like to thank Vasily Averin for reporting this issue.
Comment 8 Eugene Teo (Security Response) 2011-06-23 03:09:42 EDT
Upstream commit:
Comment 15 errata-xmlrpc 2011-08-23 10:41:53 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:1189 https://rhn.redhat.com/errata/RHSA-2011-1189.html
Comment 16 errata-xmlrpc 2011-09-12 15:44:31 EDT
This issue has been addressed in following products:

  MRG for RHEL-6 v.2

Via RHSA-2011:1253 https://rhn.redhat.com/errata/RHSA-2011-1253.html
Comment 17 errata-xmlrpc 2011-09-13 11:44:05 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:1212 https://rhn.redhat.com/errata/RHSA-2011-1212.html
Comment 19 errata-xmlrpc 2011-12-13 16:28:57 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.6.Z - Server Only

Via RHSA-2011:1813 https://rhn.redhat.com/errata/RHSA-2011-1813.html

Note You need to log in before you can comment on or make changes to this bug.