Red Hat Bugzilla – Bug 218777
CVE-2007-6733 Kernel BUG at locks:1799
Last modified: 2010-10-22 03:19:23 EDT
This problem was reported by ASANO Masahiro for the upstream kernel.
The change in locks_remove_flock for bz #160844 allows the local users to crash
the system. The nfs client prevents mandatory locking. The if statement checking
for this will allow a user to get the nfs client to leave behind posix locks by
changing the mode before unlocking. The changes in locks_remove_flock causes it
to throw a BUG().
Run the attached reproducer a few times on a RHEL 4 U4 server to cause a crash.
committed in stream U5 build 42.30. A test kernel with this patch is available
QE ack for RHEL4.5.
According to the included URL, this is a local user NFS exploit. Is there any
way this bug could be hit by an nfs server or by a user inadvertently? After a
recent kernel patch on our Sun NFS servers (to address DST), our linux CPU
server (multiple users via ssh) has crashed once about every 12 hours. Those
Sun servers have been having other issues with NFS since the patch, so I'm
wondering if it's possible that the NFS communication could cause the crash.
None of our linux workstations have had any problems, but they're likely not
hitting NFS as hard.
I applied the test kernel and so far so good. Is there a way to get an official
kernel update in FastTrack, or any word on when it might be available on the
I realize this is probably better for a mailing list, but that mail thread is
over a year old.
sucessfully tested using the reproducer and verified the patch is in the -52 kernel.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
*** Bug 208585 has been marked as a duplicate of this bug. ***
This issue has been assigned with CVE-2007-6733. It was reported back in 12/2006, and was found to be security-relevant while triaging CVE-2010-0727.
*** Bug 207737 has been marked as a duplicate of this bug. ***