mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: YangWen <anmuxixixi@gmail.com>
To: hirofumi@mail.parknet.co.jp
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fat: fix data-race between fat12_ent_put() and fat_mirror_bhs()
Date: Tue,  2 Sep 2025 20:11:34 +0800	[thread overview]
Message-ID: <20250902121134.486-1-anmuxixixi@gmail.com> (raw)
In-Reply-To: <87y0qxp6rf.fsf@mail.parknet.co.jp>

Hi,

On Tue, 02 Sep 2025 23:13:42 +0900, OGAWA Hirofumi wrote:
> Hm, what is wrong with temporary inconsistent?
> 
> If it had the race with future modification, it can be temporary
> inconsistent. However, future modification will fix it by updating with
> latest blocks, right?
> 
> Or did you actually get the inconsistent state after clean unmount?

Thanks for your comment.

This is not only a temporary in-memory inconsistency.  KCSAN detected a
race where fat12_ent_put() updates two bytes of a 12-bit FAT entry while
fat_mirror_bhs() concurrently memcpy()’s the entire sector.  The mirror
FAT may therefore receive a torn entry.

Since fat_mirror_bhs() marks those buffers dirty, the corrupted mirror
content can be flushed to disk.  In our syzkaller testing, this already
resulted in runtime errors such as:

    FAT-fs (loop4): error, clusters badly computed (421 != 418)
    FAT-fs (loop4): error, fat_bmap_cluster: request beyond EOF (i_pos 2075)

These errors occurred even after a clean unmount, which suggests that the
inconsistent FAT entries were actually written to disk and not corrected
later by "future modification".

FAT16/32 do not suffer from this problem because their entries are
naturally aligned 16/32-bit accesses, which are atomic on supported
architectures.  FAT12 is special because of the 12-bit packing across
two bytes.

So I think it is necessary to protect memcpy() in fat_mirror_bhs() with
fat12_entry_lock to avoid copying a torn FAT12 entry.

Thanks.


  parent reply	other threads:[~2025-09-02 12:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02  8:17 YangWen
2025-09-02  9:01 ` OGAWA Hirofumi
2025-09-02 12:07   ` [PATCH] drivers: example: fix memory leak YangWen
2025-09-02 12:38     ` OGAWA Hirofumi
2025-09-02 13:24       ` [PATCH] fat: fix data-race between fat12_ent_put() and fat_mirror_bhs() YangWen
2025-09-02 13:38         ` OGAWA Hirofumi
2025-09-02 14:20           ` YangWen
2025-09-02 18:05             ` OGAWA Hirofumi
2025-09-03  2:28               ` YangWen
2025-09-02 12:11   ` YangWen [this message]
2025-09-02 19:56 ` kernel test robot

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=20250902121134.486-1-anmuxixixi@gmail.com \
    --to=anmuxixixi@gmail.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --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®