mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Wenchao Hao <haowenchao2@huawei.com>
Cc: Jan Kara <jack@suse.com>,
	linux-kernel@vger.kernel.org, linfeilong@huawei.com
Subject: Re: [PATCH 0/2] Fix out-of-bound access if pagecache of udf device is corrupted
Date: Mon, 12 Jun 2023 16:40:09 +0200	[thread overview]
Message-ID: <20230612144009.s436o52pctxgctr2@quack3> (raw)
In-Reply-To: <20230613032254.1235752-1-haowenchao2@huawei.com>

On Tue 13-06-23 11:22:52, Wenchao Hao wrote:
> Following steps would cause out-of-bound access and even cause kernel
> panic when using udf:
> 
> dd if=/dev/zero of=udf.img bs=1M count=512
> mkfs.udf udf.img
> mount -o loop -t udf udf.img /mnt
> dd if=/dev/random of=/dev/loop0 bs=512 count=1 seek=128
> umount /mnt
> 
> [if /mnt is mounted on /dev/loop0]
> 
> It is because we did not check if udf_sb_info->s_lvid_bh is valid in
> udf_sb_lvidiu().
> 
> Although it's illegal to write backend device since filesystem has been
> mounted, but we should avoid kernel panic if it happened.

No, it is perfectly valid to crash the kernel if someone writes the buffer
cache of the device while the device is mounted (which your example above
does). There is no practical protection against this because someone could
overwrite the buffer just after the moment you verify its validity. The
only protection would be to lock the buffer for each access and fully
verify validity of the data after each locking but the performance and
maintenance overhead of this is too high to justify. So I'm sorry but I
will not take any patches that try to "fix" situations when someone writes
buffer cache while the filesystem is mounted.

I guess your work is motivated by some syzbot reproducer which was doing
this. Let me work on a kernel option which syzbot can use to not report
these issues.


								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2023-06-12 14:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13  3:22 Wenchao Hao
2023-06-12 14:40 ` Jan Kara [this message]
2023-06-13  1:43   ` haowenchao (C)
2023-06-13  3:22 ` [PATCH 1/2] udf: add helper function udf_check_tagged_bh to check tagged page Wenchao Hao
2023-06-13  3:22 ` [PATCH 2/2] udf:check if buffer head's data when getting lvidiu Wenchao Hao

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=20230612144009.s436o52pctxgctr2@quack3 \
    --to=jack@suse.cz \
    --cc=haowenchao2@huawei.com \
    --cc=jack@suse.com \
    --cc=linfeilong@huawei.com \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®