Re: [syzbot] [hfs?] WARNING in hfs_write_inode

[Viacheslav Dubeyko]

> On Jan 4, 2023, at 4:36 PM, Viacheslav Dubeyko <slava@xxxxxxxxxxx> wrote:
> 
> Hi Arnd,
> 
>> On Jan 4, 2023, at 2:33 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:

<skipped>

>>> 
>>> Something like this ENTIRELY UNTESTED patch?
>>> 
>>> Do we have anybody who looks at hfs?
>> 
>> Adding Viacheslav Dubeyko to Cc, he's at least been reviewing
>> patches for HFS and HFS+ somewhat recently. The linux-m68k
>> list may have some users dual-booting old MacOS.
>> 
>> Viacheslav, see the start of the thread at
>> https://lore.kernel.org/lkml/000000000000dbce4e05f170f289@xxxxxxxxxx/
>> 
> 
> Let me take a look into the issue.
> 

As far as I can see, I cannot reproduce the issue for newly created HFS volume
with simple operation of creation of several files of 4MB in size. The sync_fs
operation definitely calls hfs_write_inode() method. But I don't see such issue.

The hfs_write_inode() allocates struct hfs_find_data fd variable on stack
(fs/hfs/inode.c:426). The fd.entrylength is initialized in __hfs_brec_find()
(fs/hfs/bfind.c:100). Technically, fd->entrylength = len - keylen can introduce
overflow. But, such issue can take place for corrupted volume. Internal logic
error should result with returning error by hfs_brec_find (fs/hfs/inode.c:466):

if (hfs_brec_find(&fd))
     /* panic? */
     goto out;

And, finally, logic should end without going into the issue.

Also, as far as I can see, available volume in report (mount_0.gz) somehow corrupted already:

sudo losetup /dev/loop20 ./mount_0
sudo fsck.hfs -d /dev/loop20
** /dev/loop20
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
** Checking HFS volume.
hfs_swap_BTNode: record #1 invalid offset (0xFFF8)
   Invalid node structure
(3, 0)
   Invalid B-tree node size
(3, 0)
** Volume check failed.
volume check failed with error 7 
volume type is HFS 
primary MDB is at block 2 0x02 
alternate MDB is at block 62 0x3e 
primary VHB is at block 0 0x00 
alternate VHB is at block 0 0x00 
sector size = 512 0x200 
VolumeObject flags = 0x19 
total sectors for volume = 64 0x40 
total sectors for embedded volume = 0 0x00

So, HFS volume corruption had happened somehow earlier.
The reported issue is only a side effect of volume corruption.
The real issue of HFS volume corruption had taken place before.
And it was a silent issue somehow.

Finally, I don’t see any issue with WARN_ON() in fs/hfs/inode.c:489.
If we have some issue, then it could happen in b-tree logic or
HFS volume was corrupted somehow else. But available report doesn’t
provide any hint what could be wrong during testing.

Thanks,
Slava.