[LU-3483] Null pointer dereference in ll_revalidate_nd (llite/dcache.c) in an NFS mounted Lustre file system

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.5.0
• Labels: patch
• Environment: Lustre client >= 2.2, kernel version >= 2.6.38
• Severity: 3
• Assignee: Keith Mannthey (Inactive)
• Reporter: Patrick Farrell (Inactive)

Description

We encountered this issue when trying to use an NFS mounted Lustre file system on SLES11SP2. This issue only occurs with a client kernel version >= 2.6.38, so it does not affect SLES11SP1 or Cent OS 6.4.

In calls to ll_revalidate_nd, the nameidata pointer nd is sometimes null. The core code of the function tests for this case and handles it by calling ll_node_revalidate_it.

However, immediately before that code, there is a test to see if the LOOKUP_RCU flag is set in nd->flags. This test does NOT check to see if the nd pointer is null. Per the comment, LOOKUP_RCU was added in kernel 2.6.38, and and this code is #ifdefed accordingly.

The fix is to test if nd is null in the LOOKUP_RCU check.

Here's the revelant code:
—
int ll_revalidate_nd(struct dentry *dentry, struct nameidata *nd)
{
int rc;
ENTRY;

#ifndef HAVE_DCACHE_LOCK
/* kernel >= 2.6.38 supports rcu-walk, but lustre doesn't. */
if (nd->flags & LOOKUP_RCU)
return -ECHILD;
#endif

if (nd && !(nd->flags & (LOOKUP_CONTINUE|LOOKUP_PARENT))) {
—

So the fix is just:
if (nd && nd->flags & LOOKUP_RCU)

This issue is found in 2.2,2.3,2.4, and master, but as noted, only occurs with kernel versions greater than 2.6.38. It is NOT in 2.1, which doesn't appear to have any awareness of LOOKUP_RCU.

I will be committing the Gerrit patch shortly.