Thank you for your valuable feedback.
On Tue, 29 Apr 2025 at 02:13, Wang Zhaolong <wangzhaolong1@xxxxxxxxxx> 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
