From: Su Yue <l@damenly.su>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org, Wenqing Liu <wenqingliu0120@gmail.com>
Subject: Re: [PATCH] btrfs: tree-checker: save item data end in u64 to avoid
Date: Thu, 24 Feb 2022 23:13:57 +0800 [thread overview]
Message-ID: <7d9ks3e8.fsf@damenly.su> (raw)
In-Reply-To: <20220224143344.GU12643@twin.jikos.cz>
On Thu 24 Feb 2022 at 15:33, David Sterba <dsterba@suse.cz> wrote:
> On Tue, Feb 22, 2022 at 04:42:07PM +0800, Su Yue wrote:
>> User reported there is an array-index-out-of-bounds access
>> while
>> mounting the crafted image:
>>
>> =======================================================================
>> [ 350.411942 ] loop0: detected capacity change from 0 to
>> 262144
>> [ 350.427058 ] BTRFS: device fsid
>> a62e00e8-e94e-4200-8217-12444de93c2e
>> devid 1 transid 8 /dev/loop0 scanned by systemd-udevd (1044)
>> [ 350.428564 ] BTRFS info (device loop0): disk space caching
>> is enabled
>> [ 350.428568 ] BTRFS info (device loop0): has skinny extents
>> [ 350.429589 ]
>> [ 350.429619 ] UBSAN: array-index-out-of-bounds in
>> fs/btrfs/struct-funcs.c:161:1
>> [ 350.429636 ] index 1048096 is out of range for type 'page
>> *[16]'
>> [ 350.429650 ] CPU: 0 PID: 9 Comm: kworker/u8:1 Not tainted
>> 5.16.0-rc4
>> [ 350.429652 ] Hardware name: QEMU Standard PC (Q35 + ICH9,
>> 2009), BIOS
>> 1.13.0-1ubuntu1.1 04/01/2014
>> [ 350.429653 ] Workqueue: btrfs-endio-meta btrfs_work_helper
>> [btrfs]
>> [ 350.429772 ] Call Trace:
>> [ 350.429774 ] <TASK>
>> [ 350.429776 ] dump_stack_lvl+0x47/0x5c
>> [ 350.429780 ] ubsan_epilogue+0x5/0x50
>> [ 350.429786 ] __ubsan_handle_out_of_bounds+0x66/0x70
>> [ 350.429791 ] btrfs_get_16+0xfd/0x120 [btrfs]
>> [ 350.429832 ] check_leaf+0x754/0x1a40 [btrfs]
>> [ 350.429874 ] ? filemap_read+0x34a/0x390
>> [ 350.429878 ] ? load_balance+0x175/0xfc0
>> [ 350.429881 ] validate_extent_buffer+0x244/0x310 [btrfs]
>> [ 350.429911 ] btrfs_validate_metadata_buffer+0xf8/0x100
>> [btrfs]
>> [ 350.429935 ] end_bio_extent_readpage+0x3af/0x850 [btrfs]
>> [ 350.429969 ] ? newidle_balance+0x259/0x480
>> [ 350.429972 ] end_workqueue_fn+0x29/0x40 [btrfs]
>> [ 350.429995 ] btrfs_work_helper+0x71/0x330 [btrfs]
>> [ 350.430030 ] ? __schedule+0x2fb/0xa40
>> [ 350.430033 ] process_one_work+0x1f6/0x400
>> [ 350.430035 ] ? process_one_work+0x400/0x400
>> [ 350.430036 ] worker_thread+0x2d/0x3d0
>> [ 350.430037 ] ? process_one_work+0x400/0x400
>> [ 350.430038 ] kthread+0x165/0x190
>> [ 350.430041 ] ? set_kthread_struct+0x40/0x40
>> [ 350.430043 ] ret_from_fork+0x1f/0x30
>> [ 350.430047 ] </TASK>
>> [ 350.430047 ]
>> [ 350.430077 ] BTRFS warning (device loop0): bad eb member
>> start: ptr
>> 0xffe20f4e start 20975616 member offset 4293005178 size 2
>> =======================================================================
>>
>> btrfs check reports:
>> corrupt leaf: root=3 block=20975616 physical=20975616 slot=1,
>> unexpected
>> item end, have 4294971193 expect 3897
>>
>> The 1st slot item offset is 4293005033 and the size is 1966160.
>> In check_leaf, we use btrfs_item_end() to check item boundary
>> versus
>> extent_buffer data size. However, return type of
>> btrfs_item_end() is u32.
>> (u32)(4293005033 + 1966160) == 3897, overflow happens and the
>> result 3897
>> equals to leaf data size reasonably.
>>
>> Fix it by use u64 variable to store item data end in
>> check_leaf() to
>> avoid u32 overflow.
>>
>> This commit does solve the invalid memory access showed by the
>> stack trace.
>> However, its metadata profile is DUP and another copy of the
>> leaf is fine.
>> So the image can be mounted successfully. But when umount is
>> called,
>> the ASSERT btrfs_mark_buffer_dirty() will be trigered becase
>> the the only node
>> in extent tree has 0 item and invalid owner. It's solved by
>> another commit
>> "btrfs: check extent buffer owner against the owner rootid".
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215299
>> Reported-by: Wenqing Liu <wenqingliu0120@gmail.com>
>> Signed-off-by: Su Yue <l@damenly.su>
>
> Added to misc-next, thanks. The patch does not apply to older
> stable
> kernels due to some cleanups, should be easy to backport though.
Right. Will do it.
--
Su
next prev parent reply other threads:[~2022-02-24 15:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 8:42 [PATCH] btrfs: tree-checker: save item data end in u64 to avoid Su Yue
2022-02-24 14:33 ` David Sterba
2022-02-24 15:13 ` Su Yue [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-02-22 8:48 Su Yue
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=7d9ks3e8.fsf@damenly.su \
--to=l@damenly.su \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=wenqingliu0120@gmail.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.