From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 0/4] btrfs: lzo: Harden decompression callers to avoid kernel memory corruption.
Date: Wed, 23 May 2018 16:22:57 +0800 [thread overview]
Message-ID: <20180523082301.29874-1-wqu@suse.com> (raw)
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/lzo_corruption
Which is based on v4.17-rc5.
James Harvey reported pretty strange kernel misbehavior where after
reading certain btrfs compressed data, kernel crash with unrelated
calltrace.
(https://bugzilla.kernel.org/show_bug.cgi?id=199707 and
https://www.spinics.net/lists/linux-btrfs/msg77971.html)
Thanks for his comprehensive debug help, we located the problem to:
1) Bad lzo decompression verification check
The direct cause.
The lzo decompression code involves memory copy for compressed data
who crosses page boundary.
And if corrupted segment header contains invalid length, btrfs will
do memory copy and then corrupt kernel memory.
Fix it by add header length check for each segment, and just in case,
also add uncompressed data length check. (Patch 3)
The full explanation and kasan output can also be found in that patch.
2) Compressed extent created for NODATASUM inode
The root cause.
Will be addressed in another patchset.
Other patches are mostly cosmetic, like adding extra include for
compression.h, to avoid later compiling error. (Patch 1)
Or adding comment of how btrfs organise its compressed data (Patch 2)
And adding extra check for inlined compressed data even it's not really
possible to happen (Patch 4)
Changelog:
v2:
Cosmetic updates. Mostly for comment and gramma.
Comment and gramma fixes suggested by Nikolay.
One 4 bytes <-> LE32 convert fixes in comment.
Added reviewed-by tag for the 1st patch.
v3:
Fix comment error for inlined lzo compressed extent. (Still has
header), thanks David for pointing this out.
Add example ascii graph as an example.
Enhance inlined extent check, as header length must match with segment
header length + LZO_LEN * 2.
Qu Wenruo (4):
btrfs: compression: Add linux/sizes.h for compression.h
btrfs: lzo: Add comment about the how btrfs records its lzo compressed
data
btrfs: lzo: Add header length check to avoid slab out of bounds access
btrfs: lzo: Harden inline lzo compressed extent decompression
fs/btrfs/compression.h | 1 +
fs/btrfs/lzo.c | 81 ++++++++++++++++++++++++++++++++++++++++--
2 files changed, 80 insertions(+), 2 deletions(-)
--
2.17.0
next reply other threads:[~2018-05-23 8:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 8:22 Qu Wenruo [this message]
2018-05-23 8:22 ` [PATCH v3 1/4] btrfs: compression: Add linux/sizes.h for compression.h Qu Wenruo
2018-05-23 8:22 ` [PATCH v3 2/4] btrfs: lzo: Add comment about the how btrfs records its lzo compressed data Qu Wenruo
2018-05-23 8:23 ` [PATCH v3 3/4] btrfs: lzo: Add header length check to avoid slab out of bounds access Qu Wenruo
2018-05-24 2:09 ` Misono Tomohiro
2018-05-24 4:01 ` Qu Wenruo
2018-05-29 8:30 ` Misono Tomohiro
2018-05-29 8:51 ` Qu Wenruo
2018-05-30 4:58 ` [PATCH v4 " Qu Wenruo
2018-05-30 5:14 ` Misono Tomohiro
2018-05-30 14:47 ` David Sterba
2018-05-23 8:23 ` [PATCH v3 4/4] btrfs: lzo: Harden inline lzo compressed extent decompression Qu Wenruo
2018-05-24 17:19 ` [PATCH v3 0/4] btrfs: lzo: Harden decompression callers to avoid kernel memory corruption David Sterba
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=20180523082301.29874-1-wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).