[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251224151347.1861896-1-shardul.b@mpiricsoftware.com>
Date: Wed, 24 Dec 2025 20:43:45 +0530
From: Shardul Bankar <shardul.b@...ricsoftware.com>
To: slava@...eyko.com,
zippel@...ux-m68k.org,
linux-fsdevel@...r.kernel.org,
glaubitz@...sik.fu-berlin.de,
frank.li@...o.com
Cc: akpm@...l.org,
linux-kernel@...r.kernel.org,
janak@...ricsoftware.com,
shardulsb08@...il.com,
stable@...r.kernel.org,
syzbot+1c8ff72d0cd8a50dfeaa@...kaller.appspotmail.com,
Shardul Bankar <shardul.b@...ricsoftware.com>
Subject: [PATCH v2 0/2] hfsplus: avoid re-allocating header node 0 and stop on already-hashed nodes
Hi,
syzbot reported a warning and crash when mounting a corrupted HFS+ image where
the on-disk B-tree bitmap has node 0 (header node) marked free. In that case
hfs_bmap_alloc() can try to allocate node 0 and reach hfs_bnode_create() with
an already-hashed node number.
Patch 1 prevents allocating the reserved header node (node 0) even if the bitmap
is corrupted.
Patch 2 follows Slava's review suggestion and changes the "already hashed" path
in hfs_bnode_create() to return ERR_PTR(-EEXIST) instead of returning the existing
node pointer, so we don't continue in a non-"business as usual" situation.
v2 changes:
- Implement Slava's suggestion: return ERR_PTR(-EEXIST) for already-hashed nodes.
- Keep the node-0 allocation guard as a minimal, targeted hardening measure.
Reported-by: syzbot+1c8ff72d0cd8a50dfeaa@...kaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=1c8ff72d0cd8a50dfeaa
Link: https://lore.kernel.org/all/20251213233215.368558-1-shardul.b@mpiricsoftware.com/
Shardul Bankar (2):
hfsplus: skip node 0 in hfs_bmap_alloc
hfsplus: return error when node already exists in hfs_bnode_create
fs/hfsplus/bnode.c | 2 +-
fs/hfsplus/btree.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
--
2.34.1
Powered by blists - more mailing lists