Re: [PATCH] overlayfs: fix potential NULL pointer dereferences in file handle code

[Wang Zhaolong <wangzhaolong1@huawei.com>]

Thank you for your valuable feedback.

> On Tue, 29 Apr 2025 at 02:13, Wang Zhaolong <wangzhaolong1@huawei.com> wrote:
>>
>> Several locations in overlayfs file handle code fail to check if a file
>> handle pointer is NULL before accessing its members. A NULL file handle
>> can occur when the lower filesystem doesn't support export operations,
>> as seen in ovl_get_origin_fh() which explicitly returns NULL in this case.
> 
> Have you tried to trigger these conditions?
> 
> If you find a bug by code inspection, try to recreate it, by that you
> can also verify that the patch works.  If you cannot reproduce it, at
> least prove that triggering the bug is possible.
> 
> Without a proof the patch may turn out to do nothing at best and
> introduce new bugs at worst.
> 

I haven't yet been able to reproduce these conditions in a live environment.

My analysis started when I noticed the inconsistency in ovl_set_origin_fh()
where it accesses fh->buf without checking if fh is NULL, but then immediately
checks "fh ?" in the next parameter. Following the code paths, I found that
ovl_get_origin_fh() can explicitly return NULL when the lower filesystem
doesn't support export operations.

>>
>> The following locations are vulnerable to NULL pointer dereference:
>>
>> 1. ovl_set_origin_fh() accesses fh->buf without checking if fh is NULL
> 
> Hint: fh->buf is equivalent to &fh->buf in this case, the latter
> obviously not being a dereference.
> 
>> 2. ovl_verify_fh() uses fh->fb members without NULL check
>> 3. ovl_get_index_name_fh() accesses fh->fb.len without NULL check
> 
> These are called in the "index=on" case, which verifies at mount time
> that all layers support file handles.
> 
> Thanks,
> Miklos

Thank you for pointing out that. I'll work on creating test cases to verify
whether these NULL dereferences can actually occur in practice.

Thanks again for the guidance.

Regards,
Wang Zhaolong