linux-kernel - Re: [PATCH] fat: fix data-race between fat12_ent_put() and fat_mirror

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ecsp0yar.fsf@mail.parknet.co.jp>
Date: Tue, 02 Sep 2025 22:38:36 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: YangWen <anmuxixixi@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fat: fix data-race between fat12_ent_put() and
 fat_mirror_bhs()

YangWen <anmuxixixi@...il.com> writes:

> OGAWA Hirofumi wrote:
>> Sounds like strange. FAT driver never read the mirror FAT area in
>> runtime. Why did you think the mirror FAT affect to it?
>
> Thanks for raising this point.
>
> FAT driver itself never reads the mirror FAT at
> runtime, so this race does not directly cause runtime corruption.
>
> However, if the primary FAT on disk becomes damaged, user-space tools
> such as fsck_msdos will consult the backup FAT copies in order to
> repair it.  In that scenario, keeping the primary and backup FAT copies
> consistent is important.  If they diverge due to a race between
> fat12_ent_put() and fat_mirror_bhs(), recovery by fsck_msdos
> may become unreliable.
>
> So my intention was not to fix a runtime problem, but rather to prevent
> unnecessary inconsistencies between the primary and backup FAT copies,
> which can help later recovery tools work as expected.

You are forgetting what I said first. I said, this should be temporary
inconsistent. When unmount, temporary inconsistent should be fixed by
later write out.

IOW, I can't see why you claim this race can be the cause of permanent
inconsistent.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>