The knfsd code handling the NFSACLv2 ACCESS call has a bogus release handler defined for it. Anything that sends a proper NFSACLv2 ACCESS call over the wire to a NFSACLv2-aware NFS server can cause downstream release-ing code to chomp on the wrong hunk of memory and potentially lead to a panic. It's not clear that this code path has been tested much, and the problem has been in Linux kernels since June 2005: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a257cdd0e2179630d3201c32ba14d7fcb3c3a055 It was discovered at Connectathon 2007, largely thanks to much detective work by Greg Banks at SGI. Some workarounds are to either disable NFSv2 entirely, or disable ACLs entirely (CONFIG_NFSD_V2_ACL=n -and- CONFIG_NFSD_V3_ACL=n). The "no_acl" export option isn't sufficient, as the first NFSACL call that the client sends to probe whether ACLs work will trigger the bug before the flag is checked. And, just turning off CONFIG_NFSD_V2_ACL is insuffient, as it's paired with CONFIG_NFSD_V3_ACL checks in a lot of places.
No longer embargoed.
Created attachment 148491 [details] Proposed patch The previously attached patch was not the correct patch. A new patch has been attached which is tested and correct. Please note that RHEL-4.5 and RHEL-5.0 are not susceptible to this issue because they have the NFS_ACL v2 support completed disabled. If desired, with this patch, the NFS_ACL v2 support could be reenabled in the config-generic file.