From: Joas Antonio dos Santos <joasantonio108@gmail.com>
To: Deepanshu Kartikey <kartikey406@gmail.com>,
slava@dubeyko.com, glaubitz@physik.fu-berlin.de,
frank.li@vivo.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+c0ba772a362e70937dfb@syzkaller.appspotmail.com
Subject: Re: [PATCH v7] hfsplus: fix null-ptr-deref by creating hidden dir on remount rw
Date: Fri, 30 Oct 2026 22:23:32 -0300 [thread overview]
Message-ID: <179340981245.8403.4135841764755575334@gmail.com> (raw)
In-Reply-To: <20260717135706.42918-1-kartikey406@gmail.com>
On Fri, 17 Jul 2026 19:27:06 +0530, Deepanshu Kartikey wrote:
> hfsplus_reconfigure() does not create the hidden directory when
> remounting from read-only to read-write, leaving sbi->hidden_dir
> as NULL.
I independently reproduced the syzbot null-ptr-deref and confirm the
root cause: on a read-only mount of a volume whose on-disk "HFS+ Private
Data" directory is absent, sbi->hidden_dir stays NULL (it is created
only in hfsplus_fill_super() under !sb_rdonly). After a remount,rw,
hfsplus_unlink() -> hfsplus_cat_write_inode(sbi->hidden_dir) dereferences
the NULL inode (inode->i_sb) during rename -- the reported crash in the
[0x28-0x2f] range.
I applied v7 on c339f4010 and tested on arm64 with KASAN, using the
crafted image from the syzbot reproducer and the equivalent sequence
(mount -o ro -> mount -o remount,rw -> rename): without the patch this
oopses in hfsplus_cat_write_inode; with v7 the remount,rw creates the
hidden directory, the rename succeeds, and the KASAN splat is gone. A
normal read-write mount + rename is unaffected.
Tested-by: Joas Antonio dos Santos <joasantonio108@gmail.com>
Thanks,
Joas
prev parent reply other threads:[~2026-10-31 1:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 13:57 [PATCH v7] hfsplus: fix null-ptr-deref by creating hidden dir on remount rw Deepanshu Kartikey
2026-07-17 18:10 ` Viacheslav Dubeyko
2026-10-31 1:23 ` Joas Antonio dos Santos [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=179340981245.8403.4135841764755575334@gmail.com \
--to=joasantonio108@gmail.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=kartikey406@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=syzbot+c0ba772a362e70937dfb@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.