Re: [PATCH v3 0/3] overlayfs: security hardening patches (with PoCs)

On Mon, Jun 22, 2026 at 5:21=E2=80=AFPM Rodrigo H. <[email protected]>=
 wrote:
>
> Greg,
>
> Thank you for the previous review. I've now properly prepared the
> patches following the kernel submission process.
>
> Summary of changes:
>
> | Patch | Description | Reference |
> |-------|-------------|-----------|
> | 1/3 | Replace component walk in ovl_lookup_layer() with vfs_path_lookup=
() using LOOKUP_BENEATH | Matches ovl_lookup_data_layer() at namei.c:403-40=
4 |
> | 2/3 | Convert long refcount =E2=86=92 refcount_t; add refcount_inc_not_=
zero() in ovl_cache_get() | Per Amir's March 2024 question |
> | 3/3 | Add ovl_dir_cache_drop() helper with refcount_read() guard | Base=
d on Nirmoy Das's RFC |
>
> Testing:
>
> - PoC #1 (poc1_path_traversal.sh): Confirms that `trusted.overlay.redirec=
t`
>   with `/../etc/passwd` is blocked after PATCH 1
> - PoC #2 (poc2_refcount_race.c): 8 readdir + 8 open/close threads for 15s=
;
>   monitors dmesg for refcount_t warnings
>
> Important note on PATCH 2/3:
>
> After re-analysis of the current code, both ovl_cache_get() (readdir.c:48=
2)
> and ovl_cache_put() (readdir.c:295) execute under inode_lock exclusive
> (via WRAP_DIR_ITER and ovl_dir_release()). The long refcount is not
> currently subject to a race condition.
>
> This conversion to refcount_t is defense-in-depth =E2=80=94 it's the corr=
ect
> kernel type for reference counters and provides saturation protection.
>
> The real fixes are PATCH 1 (path traversal) and PATCH 3 (impure cache
> UAF prevention). PATCH 2 is still valid as a hardening measure.
>
> All patches are based on: ef0c9f75a195 (Nirmoy Das's commit)
> Branch: ovl-fixes-v3
>
> Full PoC scripts are attached.
>
> Thank you for your patience and guidance,
>
> Rodrigo Henrique de Souza

Rodrigo,

This patch set and report is very odd.

It claims to have POCs for security issues but I did not see any proof
that the POC reproduces a security issue.

Most of the patches range between completely incorrect, to completely
unneeded to "hardening measure without proof of need".

You even caught the false claim about race in patch #2 yourself
but the commit message still claims there is a race.

On top of that, attaching patches is not how you submit patches to the kern=
el
and these patches are of no interest to the security mailing list.

Please be respectful of maintainers time and do not send
anymore AI generated overlayfs patches before you yourself
have a full understanding of the problem a real reproducer of
the problem and a real understanding of the solution.

If you have a real reproducer, without a good understanding of
the code, you can send a bug report.

Thanks,
Amir.