mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Baokun Li <libaokun1@huawei.com>
To: 余昊铖 <3230100410@zju.edu.cn>
Cc: <security@kernel.org>, <linux-ext4@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ext4: Fix KASAN use-after-free in ext4_find_extent
Date: Thu, 18 Dec 2025 09:49:31 +0800	[thread overview]
Message-ID: <7e3278d0-032c-447a-a4f4-0a34a09541f1@huawei.com> (raw)
In-Reply-To: <2ef68a02.45e3e.19b2ce7b7a0.Coremail.3230100410@zju.edu.cn>

On 2025-12-17 23:22, 余昊铖 wrote:
> Hi,
>
> Sorry but I am a bit confused by your words. My original fuzz tesing already enabled CONFIG_BLK_DEV_WRITE_MOUNTED as in most major Linux distributions. 
>
> So does a bug found when CONFIG_BLK_DEV_WRITE_MOUNTED is enabled still hold value for reporting? Should I enable or disable this configuration in my future fuzzing work?

Oh, my apologies—I mistakenly wrote "enable" instead of "disable" which
must have been confusing.

Distributions typically enable this config because some userspace tools
still rely on writing directly to the raw disk. Once all userspace tools
transition to using ioctls, we will be able to disable it globally or
specifically for certain filesystems in distributions.

However, during testing, this feature is often disabled to avoid false
positives by prohibiting raw writes that bypass the filesystem.

You can find more details in the original patchset if you're interested:
https://lore.kernel.org/all/20231101173542.23597-1-jack@suse.cz


Cheers,
Baokun

>
> Thanks,
> Haocheng Yu
>
>>> Hi,
>>>
>>> I have disabled CONFIG_BLK_DEV_WRITE_MOUNTED and spent some time trying to trigger the reported KASAN issues. And I found neither of the two bugs has been observed since. Is this issue still worth investigating?
>> That essentially confirms the issue is caused by bypassing the
>> filesystem to write directly to the raw disk. This is a known
>> issue and is quite tricky to solve.
>>
>> You can work around this specific class of issues in your fuzz
>> testing by enabling CONFIG_BLK_DEV_WRITE_MOUNTED. Syzbot runs
>> with this configuration enabled by default.
>>
>>
>> Cheers,
>> Baokun



  reply	other threads:[~2025-12-18  1:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-09 12:27 余昊铖
2025-12-14  3:17 ` Theodore Tso
2025-12-14  8:52   ` 余昊铖
2025-12-15  1:54 ` Baokun Li
2025-12-15 11:11   ` 余昊铖
2025-12-15 12:42     ` Baokun Li
2025-12-17 15:22       ` 余昊铖
2025-12-18  1:49         ` Baokun Li [this message]
2025-12-18  5:42           ` 余昊铖

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=7e3278d0-032c-447a-a4f4-0a34a09541f1@huawei.com \
    --to=libaokun1@huawei.com \
    --cc=3230100410@zju.edu.cn \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=security@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®