All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
	xfs-masters@oss.sgi.com, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH][RFC][resend] potential NULL pointer deref in XFS on failed mount
Date: Fri, 17 Nov 2006 09:09:58 +1100	[thread overview]
Message-ID: <20061116220958.GE11034@melbourne.sgi.com> (raw)
In-Reply-To: <200611162218.26945.jesper.juhl@gmail.com>

On Thu, Nov 16, 2006 at 10:18:26PM +0100, Jesper Juhl wrote:
> (got no reply on this when I originally send it on 20061031, so resending
>  now that a bit of time has passed.  The patch still applies cleanly to
>  Linus' git tree as of today.)
> 
> 
> The Coverity checker spotted a potential problem in XFS.
> 
> The problem is that if, in xfs_mount(), this code triggers:
> 
> 	...
> 	if (!mp->m_logdev_targp)
> 		goto error0;
> 	...
> 
> Then we'll end up calling xfs_unmountfs_close() with a NULL 
> 'mp->m_logdev_targp'. 
> This in turn will result in a call to xfs_free_buftarg() with its 'btp' 
> argument == NULL. xfs_free_buftarg() dereferences 'btp' leading to
> a NULL pointer dereference and crash.

Interesting that coverity found that, but failed to find the other
leaks in that function from exactly the same code and error
case.....

> I think this can happen, since the fatal call to xfs_free_buftarg() 
> happens when 'm_logdev_targp != m_ddev_targp' and due to a check of
> 'm_ddev_targp' against NULL in xfs_mount() (and subsequent return if it is 
> NULL) the two will never both be NULL when we hit the error0 label from 
> the two lines cited above.
> 
> Comments welcome (please keep me on Cc: on replies).
> 
> Here's a proposed patch to fix this by testing 'btp' against NULL in 
> xfs_free_buftarg().

Not the right fix - we should only be trying to free valid
buftargs, which means xfs_unmountfs_close() is the correct
place to fix this....

e.g:

-	if (mp->m_logdev_targp != mp->m_ddev_targp)
+	if (mp->m_logdev_targp && (mp->m_logdev_targp != mp->m_ddev_targp))

As to the afore-mentioned leaks, if we fail to allocate a realtime
buftarg, then we will leak a reference to both the rtdev and logdev,
and if we fail to allocate an external log buftarg we'll leak a
reference to the logdev. i.e., we fail to do one or both of:

	xfs_blkdev_put(logdev);
	xfs_blkdev_put(rtdev);

To remove the bdev references we may have gained earlier. Normally,
these references are released by xfs_free_buftarg(), but because we
failed to allocate the buftarg, we can't drop the references via
that method....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  parent reply	other threads:[~2006-11-16 22:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-16 21:18 [PATCH][RFC][resend] potential NULL pointer deref in XFS on failed mount Jesper Juhl
2006-11-16 21:23 ` Shailendra Tripathi
2006-11-16 21:43   ` Jesper Juhl
2006-11-16 21:44     ` Shailendra Tripathi
2006-11-16 22:09 ` David Chinner [this message]
2006-11-16 22:18   ` Jesper Juhl
2006-11-20 14:32     ` Jesper Juhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061116220958.GE11034@melbourne.sgi.com \
    --to=dgc@sgi.com \
    --cc=akpm@osdl.org \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs-masters@oss.sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.