From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Cc: linux-fsdevel@vger.kernel.org
Subject: [PATCH 6/5]: XFS: Prevent use-after-free caused by synchronous inode reclaim
Date: Thu, 9 Oct 2008 15:21:34 +1100 [thread overview]
Message-ID: <20081009042134.GD9597@disturbed> (raw)
In-Reply-To: <1223416332-7026-1-git-send-email-david@fromorbit.com>
Folks,
The following patch fixes a use after free I just found.
It appears that switching between SLAB and SLUB seems to
turn off slab/slub memory poisoning, so i dƣdn't realise
I'd be running for some time without poisoning turned on.
Once I turned poisoning back on I found this use-after-free
immediately on the first unmount trying to reclaim a clean
realtime bitmap inode.
With this patch, the netire patchset that I posted yesterday
passes xfsqa with memory poisoning turned on.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
XFS: Prevent use-after-free caused by synchronous inode reclaim
With the combined linux and XFS inode, we need to ensure that the
combined structure is not freed before the generic code is finished
with the inode. As it turns out, there is a case where the XFS inode
is freed before the linux inode - when xfs_reclaim() is called from
->clear_inode() on a clean inode, the xfs inode is freed during
that call. The generic code references the inode after the
->clear_inode() call, so this is a use after free situation.
Fix the problem by moving the xfs_reclaim() call to ->destroy_inode()
instead of in ->clear_inode(). This ensures the combined inode
structure is not freed until after the generic code has finished
with it.
---
fs/xfs/linux-2.6/xfs_super.c | 32 ++++++++++++++------------------
1 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c
index b893f8c..7e5a9b7 100644
--- a/fs/xfs/linux-2.6/xfs_super.c
+++ b/fs/xfs/linux-2.6/xfs_super.c
@@ -875,13 +875,18 @@ xfs_fs_alloc_inode(
}
/*
- * we need to provide an empty inode free function to prevent
- * the generic code from trying to free our combined inode.
+ * Now that the generic code is guaranteed not to be accessing
+ * the linux inode, we can reclaim the inode.
*/
STATIC void
xfs_fs_destroy_inode(
struct inode *inode)
{
+ xfs_inode_t *ip = XFS_I(inode);
+
+ XFS_STATS_INC(vn_reclaim);
+ if (xfs_reclaim(ip))
+ panic("%s: cannot reclaim 0x%p\n", __func__, inode);
}
/*
@@ -958,22 +963,13 @@ xfs_fs_clear_inode(
{
xfs_inode_t *ip = XFS_I(inode);
- /*
- * ip can be null when xfs_iget_core calls xfs_idestroy if we
- * find an inode with di_mode == 0 but without IGET_CREATE set.
- */
- if (ip) {
- xfs_itrace_entry(ip);
- XFS_STATS_INC(vn_rele);
- XFS_STATS_INC(vn_remove);
- XFS_STATS_INC(vn_reclaim);
- XFS_STATS_DEC(vn_active);
-
- xfs_inactive(ip);
- xfs_iflags_clear(ip, XFS_IMODIFIED);
- if (xfs_reclaim(ip))
- panic("%s: cannot reclaim 0x%p\n", __func__, inode);
- }
+ xfs_itrace_entry(ip);
+ XFS_STATS_INC(vn_rele);
+ XFS_STATS_INC(vn_remove);
+ XFS_STATS_DEC(vn_active);
+
+ xfs_inactive(ip);
+ xfs_iflags_clear(ip, XFS_IMODIFIED);
}
STATIC void
next prev parent reply other threads:[~2008-10-09 4:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 21:52 [PATCH 0/5] Combine the XFS and Linux inode structures V2 Dave Chinner
2008-10-07 21:52 ` [PATCH 1/5] XFS: factor xfs_iget_core() into hit and miss cases Dave Chinner
2008-10-07 21:52 ` [PATCH 2/5] XFS: Never call mark_inode_dirty_sync() directly Dave Chinner
2008-10-07 21:52 ` [PATCH 3/5] Inode: Allow external initialisers Dave Chinner
2008-10-14 7:00 ` Lachlan McIlroy
2008-10-14 6:53 ` Dave Chinner
2008-10-14 12:55 ` Christoph Hellwig
2008-10-15 1:09 ` Lachlan McIlroy
2008-10-07 21:52 ` [PATCH 4/5] Inode: Allow external list initialisation Dave Chinner
2008-10-07 21:52 ` [PATCH 5/5] XFS: Combine the XFS and Linux inodes V3 Dave Chinner
2008-10-09 4:21 ` Dave Chinner [this message]
2008-10-09 7:02 ` [PATCH 6/5]: XFS: Prevent use-after-free caused by synchronous inode reclaim Christoph Hellwig
2008-10-09 8:07 ` Dave Chinner
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=20081009042134.GD9597@disturbed \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox