Re: [PATCH] f2fs: reject non-directory inode in f2fs_get_parent() to prevent null-ptr-deref

[ZhengYuan Huang]

On Wed, Mar 18, 2026 at 7:39 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> Does the f2fs fsck tool catch this issue when run on the corrupted
> image?

This issue was found by our fuzzing tool. We are still minimizing the
reproducer and checking whether fsck.f2fs catches this case, so that
part is not concluded yet. I would appreciate a bit more time on that.

> That is not a valid threat model, sorry.  If you can modify a filesystem
> image while it is mounted, this is the least of your worries :)

Thank you very much for taking the time to review the report and for
your reply. I really appreciate it.

I understand your point about runtime corruption not necessarily being
the primary threat model. I just wanted to provide a bit more context
on why I thought this case might still be worth reporting.

Our fuzzing tool does not aim to model an attacker with arbitrary
write access to a mounted filesystem image. What it does is apply
small metadata mutations during runtime in order to test filesystem
robustness when the kernel is exposed to inconsistent on-disk state.

I thought this might still be relevant from two angles:

1. Accidental media corruption at runtime

In practice, storage may return inconsistent metadata while mounted
due to bit flips, faulty firmware, transient I/O issues, or partial
writes. In that situation, even if the filesystem metadata is no
longer trustworthy, it still seems desirable that the kernel reject
the invalid state cleanly rather than hit a NULL dereference in a
deeper path.

2. Remote / distributed storage setups

In some cloud or distributed-storage environments, the machine serving
the backing data may be buggy or compromised, or the data may become
corrupted in transit. From the client kernel’s perspective, this is
again similar to receiving malformed metadata from the storage layer,
so I thought it might be worth ensuring that such cases do not affect
overall kernel stability.

I also noticed that f2fs already seems to contain some defensive
checks for unexpected runtime state. For example, in fs/f2fs/segment.c
there is the comment:

/*
* If checkpoints are off, we must not reuse data that
* was used in the previous checkpoint. If it was used
* before, we must track that to know how much space we
* really have.
*/

and there is also the extra __check_sit_bitmap() verification before
submission. That made me think f2fs does already try to guard against
certain forms of runtime inconsistency or corruption.

So my thought here was only that f2fs_get_parent() might want to
enforce its expected invariant a bit earlier, since
export_operations::get_parent should only operate on directory
dentries. The S_ISDIR() check seemed like a small defensive validation
that prevents the later NULL dereference.

I am still learning filesystem design and implementation, so if my
understanding above is incorrect, I would really appreciate any
correction.

Thanks again for your time.

Best regards,
ZhengYuan Huang