[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <93338c04-75d4-474e-b2d9-c3ae6057db96@I-love.SAKURA.ne.jp>
Date: Fri, 18 Jul 2025 07:08:24 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Viacheslav Dubeyko <Slava.Dubeyko@....com>,
"willy@...radead.org" <willy@...radead.org>
Cc: "glaubitz@...sik.fu-berlin.de" <glaubitz@...sik.fu-berlin.de>,
"frank.li@...o.com" <frank.li@...o.com>,
"slava@...eyko.com" <slava@...eyko.com>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3] hfs: remove BUG() from
hfs_release_folio()/hfs_test_inode()/hfs_write_inode()
On 2025/07/18 4:49, Viacheslav Dubeyko wrote:
> I assume if we created the inode as normal with i_ino == 0, then we can make it
> as a dirty. Because, inode will be made as bad inode here [2] only if rec->type
> is invalid. But if it is valid, then we can create the normal inode even with
> i_ino == 0.
You are right. The crafted filesystem image in the reproducer is hitting HFS_CDR_DIR with
inode->i_ino = 0 ( https://elixir.bootlin.com/linux/v6.16-rc6/source/fs/hfs/inode.c#L363 ).
Powered by blists - more mailing lists