All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: darrick.wong@oracle.com
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH v2 0/5] xfs: fix buf log item memory corruption on non-amd64
Date: Thu, 09 Jan 2020 10:44:40 -0800	[thread overview]
Message-ID: <157859548029.164065.5207227581806532577.stgit@magnolia> (raw)

Hi all,

This second series corrects a memory corruption problem that I noticed
when running fstests on i386 and on a 64k-page aarch64 machine.  The
root cause is the fact that on v5 filesystems, a remote xattribute value
can be allocated 128K of disk space (64k for the value, 64 bytes for the
header).

xattr invalidation will try to xfs_trans_binval the attribute value
buffer, which creates a (zeroed) buffer log item.  The dirty buffer in
the buffer log item isn't large enough to handle > 64k of dirty data and
we write past the end of the array, corrupting memory.  On amd64 the
compiler inserts an invisible padding area just past the end of the
dirty bitmap, which is why we don't see the problem on our laptops. :P

Since we don't ever log remote xattr values, we can fix this problem by
making sure that no part of the code that handles remote attr values
ever supplies a transaction context to a xfs_buf function.  Finish the
series by adding a few asserts so that we'll shut down the log if this
kind of overrun ever happens again.

This has been lightly tested with fstests.  Enjoy!
Comments and questions are, as always, welcome.

--D

             reply	other threads:[~2020-01-09 18:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 18:44 Darrick J. Wong [this message]
2020-01-09 18:44 ` [PATCH 1/5] xfs: refactor remote attr value buffer invalidation Darrick J. Wong
2020-01-10 11:55   ` Christoph Hellwig
2020-01-14  0:43     ` Darrick J. Wong
2020-01-09 18:44 ` [PATCH 2/5] xfs: fix memory corruption during " Darrick J. Wong
2020-01-10 11:57   ` Christoph Hellwig
2020-01-14  0:59     ` Darrick J. Wong
2020-01-09 18:45 ` [PATCH 3/5] xfs: clean up xfs_buf_item_get_format return value Darrick J. Wong
2020-01-10 11:58   ` Christoph Hellwig
2020-01-09 18:45 ` [PATCH 4/5] xfs: complain if anyone tries to create a too-large buffer log item Darrick J. Wong
2020-01-10 11:58   ` Christoph Hellwig
2020-01-09 18:45 ` [PATCH 5/5] xfs: make struct xfs_buf_log_format have a consistent size Darrick J. Wong
2020-01-10 11:59   ` Christoph Hellwig
2020-01-10 16:53     ` Darrick J. Wong

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=157859548029.164065.5207227581806532577.stgit@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    /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.