CVE-2011-2491: Medium severity linux kernel vulnerability
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.
Details: flock on NFS calls nlmclntlock() function, where nlmclntcall() executes synchronous RPC task NLMPROCLOCK. Via several subcalls (callbind) it successfully connects to NFS server and decodes its reply, however because server did not set up rport rpcbgetportdone() returns -EACCES, and following rpc subcall callbindstatus() in this case repeats callbind() after 3 sec timeout.
It isn't a big problem, and this cycle could be broken by signal, however error path of nlmclntlock() 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 nlmclntlock(), check it on error path and do not execute NLMPROCUNLOCK call because we already know that server does not support locking operations.
PS. one more separate issue: NLMPROCUNLOCK can be cycled in another place: nlmclntunlockcallback() restarts RPC task in case of any errors. Therefore we cannot execute NLMPROCUNLOCK 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): 2.6.32-131.0.15.el6.x8664 I've reproduced this issue on RHEL5, RHEL6, ubuntu 11.04 and upstream linux kernel 2.6.39.
How reproducible: 100%
Actual results: flock hangs, can be canceled by signal, as result one more rpc task leaks (FYI: sysctl -w sunrpc.rpcdebug=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
Other sources
The Network Lock Manager (NLM) protocol implementation in the NFS client functionality in the Linux kernel before 3.0 allows local users to cause a denial of service (system hang) via a LOCKUN flock system call.
— Launchpad
Affected Software
Remediation
Patch Available
Patch Available
Event History
Frequently Asked Questions
What is the severity of CVE-2011-2491?
CVE-2011-2491 is classified as a moderate severity vulnerability.
How do I fix CVE-2011-2491?
To remediate CVE-2011-2491, update your Linux kernel to version 3.0 or later.
What software is affected by CVE-2011-2491?
CVE-2011-2491 affects Linux kernels prior to version 3.0 and specific versions of Red Hat Enterprise Linux 5.0.
What type of vulnerability is CVE-2011-2491?
CVE-2011-2491 is a vulnerability related to improper privilege management in the Linux kernel.
Is CVE-2011-2491 exploitable remotely?
CVE-2011-2491 is not typically exploitable remotely but may be leveraged in local attacks.