linux-toradex.git/fs/hfsplus, branch master

Merge tag 'hfs-v7.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/hfs

2026-10-21T02:06:21+00:00

Pull hfs/hfsplus updates from Viacheslav Dubeyko:
 "Fix {hfs,hfsplus}_btree_close() (Bruno Produit):
   - B-tree nodes with a zero reference count remain in the node hash
     until folio reclaim or tree teardown frees them. The folio release
     callbacks remove nodes while holding hash_lock, but
     hfs_btree_close() walks and frees the same hash without that lock.
     Reclaim can therefore unhash and free a node after close has loaded
     its pointer, causing a use-after-free or double-free. Detach each
     node with hfs_bnode_unhash() while holding hash_lock before
     inspecting and freeing it. Drop the lock before hfs_bnode_free() so
     a large tree is not freed while holding a spinlock.

  Fix hfs_inode_setattr() and hfs_brec_insert() (Davy Felipe):
   - hfs_inode_setattr() rejects unsupported UID, GID and mode changes,
     but returns the value stored in error when the filesystem is not
     mounted with the quiet option. At this point error is zero, as
     execution has already passed a successful setattr_prepare() call.
     As a result, unsupported attribute changes are incorrectly reported
     to userspace as successful even though the inode remains unchanged.
     Return -EPERM for these operations while preserving the existing
     behavior for quiet mounts.
   - hfs_brec_insert() may fail while inserting a new extent record, but
     __hfs_ext_write_extent() currently ignores its return value and
     clears HFS_FLG_EXT_DIRTY and HFS_FLG_EXT_NEW as if the insertion
     had succeeded. Use a reusable B-tree node range helper that takes
     the find data and the expected record size. The helper validates
     the bnode and tree pointers, entry offset and entry length, and
     ensures that the write range fits within the node.

  Fix failure in xfstests generic/339 (Viacheslav Dubeyko):
   - The test left an HFS+ volume corrupted and, as a result,
     fsck.hfsplus reported a long run of "Illegal name". The root cause
     is that fs/hfsplus/unicode.c's decomposition table (Apple Technote
     #1150) decomposes each source character entirely on its own and
     never does anything further with the result. Real fsck_hfs has
     carried a permanent "FixDecomps" fixup in CatalogCheck.c for
     exactly what that leaves unhandled. The fix makes hfsplus store,
     hash and compare names the same way current macOS does"

* tag 'hfs-v7.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/hfs:
  hfs: handle extent B-tree write errors
  hfsplus: add KUnit coverage for canonical reordering and legacy fixups
  hfsplus: canonicalize decomposed catalog names like fsck_hfs expects
  hfsplus: add Unicode combining-class and legacy decomposition data
  hfs/hfsplus: serialize B-tree close against folio release
  hfs: return -EPERM for unsupported setattr changes

hfsplus: add KUnit coverage for canonical reordering and legacy fixups

2026-09-25T19:36:04+00:00

Add regression tests for checking that decomposed catalog names
get canonically reordered and legacy-decomposition corrected
before storage, matching what macOS's own fsck_hfs requires and
previously flagged as "Illegal name" (reproducible via xfstests
generic/339).

Two small helpers, test_char2uni_utf8()/test_uni2char_utf8(), wrap the
real utf8_to_utf32()/utf32_to_utf8() codec: the existing
test_char2uni()/test_uni2char() stand-ins only handle one raw byte per
character and can't represent the multi-byte combining marks (U+0301,
U+0323, ...) these tests need.

New cases:

 - hfsplus_asc2uni_combining_reorder_test: two independently-typed
   combining marks (U+0301 class 230, U+0323 class 220) end up stored
   in ascending combining-class order regardless of typed order, are
   left alone when already canonical, and keep their relative order
   when their classes are equal (the sort must be stable).
 - hfsplus_unicode_combining_reorder_roundtrip_test: a name stored with
   marks reordered still reads back as the same, valid UTF-8.
 - hfsplus_asc2uni_legacy_decomp_test: U+01F8 decomposes to "N" +
   U+0300 even though Apple Technote #1150's table has no entry for it.
 - hfsplus_asc2uni_legacy_seq_fixup_test: a Greek letter + U+030D
   becomes that letter + U+0301, and Bengali BA + NUKTA collapses to
   the single letter RA WITH MIDDLE DIAGONAL.
 - hfsplus_hash_dentry_combining_reorder_test: two names differing only
   in typed mark order hash identically, since both canonicalize to the
   same stored form.
 - hfsplus_compare_dentry_combining_reorder_test and
   hfsplus_compare_dentry_legacy_decomp_test: likewise, both compare
   equal - a precomposed U+01F8 and its already-decomposed "N" + U+0300
   spelling must be found as the same catalog entry.

All 34 cases in the hfsplus_unicode KUnit suite (27 existing + 7 new)
pass under tools/testing/kunit/kunit.py.

Signed-off-by: Viacheslav Dubeyko 
Link: https://lore.kernel.org/r/20260919001607.2777138-4-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko

hfsplus: canonicalize decomposed catalog names like fsck_hfs expects

2026-09-25T19:36:04+00:00

hfsplus_decompose_table (Apple Technote #1150) decomposes each source
character entirely on its own. It never reorders the result, and it
predates a handful of later corrections to the decomposition standard.
Two concrete consequences, both of which macOS's own fsck_hfs treats as
"Illegal name" (CatalogCheck.c: CheckCatalogName(), FixDecomps()):

 - When combining marks contributed by two different source characters
   end up adjacent, this driver stores them in input order rather than
   ascending Unicode combining-class order.
 - A small, fixed set of characters either aren't decomposed at all,
   or are decomposed into a sequence macOS corrected back in
   Mac OS X 10.2 ("Jaguar").

This is reliably reproducible: xfstests generic/339 exercises dirhash
collisions by creating many files with randomized Unicode names, and
the resulting HFS+ volume fails _check_generic_filesystem afterward
with a long run of "Illegal name" reports from fsck.hfsplus.

Fix hfsplus_asc2uni() to store names the way current macOS does, using
the Unicode tables:

 - hfsplus_canonical_reorder() applies the Unicode Canonical Ordering
   Algorithm: each maximal run of nonzero-combining-class code units is
   stable-sorted into ascending class order.
 - decompose_unichar() falls back to hfsplus_legacy_decompose() for the
   characters missing from Apple Technote #1150's table.
 - hfsplus_fixup_legacy_sequences() substitutes any of fsck_hfs's known
   bad sequences with their corrected form.

hfsplus_decompose_str() ties these together and is now shared by
hfsplus_asc2uni(), hfsplus_hash_dentry() and hfsplus_compare_dentry(),
so hashing and comparison always agree with what actually gets stored -
otherwise two byte-for-byte different but canonically-equivalent
spellings of a name could hash differently or fail to compare equal
against the catalog entry a create() of either would produce.

cc: John Paul Adrian Glaubitz 
cc: Yangtao Li 
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Viacheslav Dubeyko 
Link: https://lore.kernel.org/r/20260919001607.2777138-3-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko

hfsplus: add Unicode combining-class and legacy decomposition data

2026-09-25T19:36:04+00:00

macOS's own fsck_hfs rejects a catalog name as "Illegal name" in two
cases this driver's decomposition tables don't currently account for:

 - a decomposed name whose combining marks aren't in Unicode canonical
   combining-class order (fsck_hfs's FixDecomps(), CatalogCheck.c);
 - a small, fixed set of characters whose canonical decomposition either
   wasn't yet defined, or was later corrected, since the driver's
   existing hfsplus_decompose_table (Apple Technote #1150) predates
   those corrections, which macOS has applied since Mac OS X 10.2
   ("Jaguar", 2002).

This is purely a data patch and adds no new behavior on its own:

 - hfsplus_ccc_table: canonical combining class per BMP code point,
   generated from the Unicode Character Database version 12.1.0
   (https://www.unicode.org/Public/12.1.0/ucd/extracted/
   DerivedCombiningClass.txt), the same UCD version fs/unicode's
   README.utf8data documents.

 - hfsplus_legacy_decomp_table and hfsplus_legacy_seq_fixups: the
   corrected decompositions and sequence replacements fsck_hfs itself
   requires, decoded from hfsprogs 540.1's
   fsck_hfs.tproj/dfalib/DecompData.h (upstream: Apple's diskdev_cmds,
   https://opensource.apple.com/source/diskdev_cmds/).

The three new struct types and the extern declarations for all of
tables.c's tables (existing and new) move into a new fs/hfsplus/
unicode.h, replacing the ad hoc externs that used to live in
hfsplus_fs.h.

cc: John Paul Adrian Glaubitz 
cc: Yangtao Li 
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Viacheslav Dubeyko 
Link: https://lore.kernel.org/r/20260919001607.2777138-2-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko

hfs/hfsplus: serialize B-tree close against folio release

2026-09-25T19:21:29+00:00

B-tree nodes with a zero reference count remain in the node hash until
folio reclaim or tree teardown frees them.  The folio release callbacks
remove nodes while holding hash_lock, but hfs_btree_close() walks and
frees the same hash without that lock.  Reclaim can therefore unhash and
free a node after close has loaded its pointer, causing a use-after-free
or double-free.

The following syzkaller crashes seem to be the same UAF in
{hfs,hfsplus}_btree_close() (or {hfs,hfsplus}_bnode_unhash()) and follow
the same pattern, but do not contain a reproducer to confirm.

Detach each node with hfs_bnode_unhash() while holding hash_lock before
inspecting and freeing it.  Drop the lock before hfs_bnode_free() so a
large tree is not freed while holding a spinlock.  Apply the same fix to
the matching HFS+ implementation.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+d729df28d933979e017a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d729df28d933979e017a
Reported-by: syzbot+2eac7d175baf21e6a5d5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2eac7d175baf21e6a5d5
Reported-by: syzbot+7155b2fe09e033c91381@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7155b2fe09e033c91381
Reported-by: syzbot+adeb387cede15eb11607@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=adeb387cede15eb11607
Reported-by: syzbot+ae7f2423f3648100506d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ae7f2423f3648100506d
Assisted-by: Codex:gpt-5.6-sol
Reported-by: Kyle Zeng 
Signed-off-by: Kyle Zeng 
Signed-off-by: Bruno Produit 
Reviewed-by: Viacheslav Dubeyko 
Tested-by: Viacheslav Dubeyko 
Link: https://lore.kernel.org/r/20260921153729.600313-1-bruno.produit@trailofbits.com
Signed-off-by: Viacheslav Dubeyko

fs: port ->setattr() to pass const mnt_idmap

2026-09-23T07:19:51+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-24-54ccd48e100b@kernel.org
Acked-by: Paul Moore 
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

fs: port ->getattr() to pass const mnt_idmap

2026-09-23T07:19:51+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-23-54ccd48e100b@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

fs: port ->create() to pass const mnt_idmap

2026-09-23T07:19:51+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-22-54ccd48e100b@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

fs: port ->symlink() to pass const mnt_idmap

2026-09-23T07:19:50+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-21-54ccd48e100b@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

fs: port ->mkdir() to pass const mnt_idmap

2026-09-23T07:19:50+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-20-54ccd48e100b@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)