Bug 16259 - vfs_glusterfs: smbd crash in pub_glfs_close() on GlusterFS 11.x due to libgfapi refcount bug
Summary: vfs_glusterfs: smbd crash in pub_glfs_close() on GlusterFS 11.x due to libgfa...
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 4.24.3
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-09-22 15:29 UTC by Thales
Modified: 2026-09-22 20:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thales 2026-09-22 15:29:42 UTC
Tracks smbd aborts on GlusterFS 11.x triggered by the fix for bug 16043 (4.23.7, 4.24.2, master) while the upstream fix gluster/glusterfs#4798 is pending.

Root cause (upstream): libgfapi's glfs_*at() calls release the parent directory handle twice when a lookup fails with anything other than ENOENT, so the handle smbd still holds is freed (gluster/glusterfs#4796; fix proposed with a regression test in
  gluster/glusterfs#4798, under review). Present in every 11.x release since the *at() API arrived in 11.0 (2022). The change is confined to api/src/glfs-fops.c and applies unchanged to release-11 (v11.2).

How smbd reaches it: vfs_gluster_fstatat()/vfs_gluster_openat() pass the directory handle as the at()-parent (since 4.17.0, bug 15157), and directory listings issue SMB_VFS_FSTATAT() relative to the open directory handle (since 4.19.0; 4.20.0 added   the pathref opens relative to it). One entry failing with ENOTDIR, EACCES, or ENOTCONN during a transport disconnect frees the directory handle behind smbd's back.

Effect of the 16043 fix: closing the handle at session logoff turns an existing silent invalid-handle state (the listing returned EBADF for the rest of the session and the handle leaked) into an abort in pub_glfs_close() <- vfs_gluster_fsp_ext_destroy() once the allocator has reused the block, which is the normal case in a busy smbd.

Observed on a production gateway (Samba 4.23.6 with the 16043 backport, GlusterFS 11.2):
    * 11 smbd cores in two days across 6 clients
    * 10 at session logoff, in pub_glfs_close() from the destructor
    * 1 in pub_glfs_openat() relative to an already freed parent

Stable branches: reverting bug 16043 restores the unbounded fd leak and does not prevent the openat-relative crash. If the fix is kept, a known-issue entry for 4.23.x/4.24.x would tell affected sites what to do while libgfapi is unfixed. Distributions that ship both projects can carry the glfs-fops.c change in their libgfapi package.

Evidence in gluster/glusterfs#4796: ASan traces of the double release for openat/fstatat/renameat/renameat2, a reproducer, the regression test (fails on unfixed devel, passes with the fix), and the smbd backtraces. Available to test patches or  backports on the affected gateway.
Comment 1 Anoop C S 2026-09-22 18:28:32 UTC
Thanks for letting us know. However, your analysis itself indicates that Samba is not responsible for fixing this bug, as libgfapi appears to be the culprit. Unfortunately, in such cases, we generally do not consider ourselves responsible for mentioning the issue in the release notes, which are derived from the WHATSNEW text. Unless there is evidence to the contrary, please feel free to close the bug report.
Comment 2 Thales 2026-09-22 20:17:35 UTC
As per the review, this is glusterfs upstream territory for fixing.