public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Jianzhou Zhao <luckd0g@163.com>
Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: BUG: KCSAN: data-race in _copy_to_iter / ext4_generic_delete_entry
Date: Wed, 11 Mar 2026 10:40:07 -0400	[thread overview]
Message-ID: <20260311144007.GA69804@macsyma-wired.lan> (raw)
In-Reply-To: <6c4b2013.6d16.19cdbecff3e.Coremail.luckd0g@163.com>

On Wed, Mar 11, 2026 at 04:04:28PM +0800, Jianzhou Zhao wrote:
> Subject: [BUG] ext4: KCSAN: data-race in _copy_to_iter / ext4_generic_delete_entry
> 
> Dear Maintainers,
> 
> We are writing to report a KCSAN-detected data race vulnerability
> within `ext4` and the block device layer. This bug was found by our
> custom fuzzing tool, RacePilot. The race occurs when
> `ext4_generic_delete_entry` modifies the `rec_len` of a previous
> directory entry (via a 2-byte write) during a path unlink operation,
> while a concurrent thread directly accesses the raw block device of
> the mounted filesystem (via `read()`), executing `_copy_to_iter()`
> which blindly bulk-reads the buffer underlying the filesystem page
> cache. We observed this bug on the Linux kernel version
> 6.18.0-08691-g2061f18ad76e-dirty.

Any attempts to read from a block device while it is mounted is
subject to arbitrary race conditions; there is no guarantee that the
file system contents accessed by userspace is going to be consistent.
In fact, it's practically guaranteed that it will not be consistent.

So this is considered NOTABUG.

					- Ted

      reply	other threads:[~2026-03-11 14:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11  8:04 BUG: KCSAN: data-race in _copy_to_iter / ext4_generic_delete_entry Jianzhou Zhao
2026-03-11 14:40 ` Theodore Tso [this message]

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=20260311144007.GA69804@macsyma-wired.lan \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luckd0g@163.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox