https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295577
Bug ID: 295577
Summary: smbfs: smbfs_node_alloc() leaks name buffers when
insmntque() fails
Product: Base System
Version: 14.4-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Created attachment 271120
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=271120&action=edit
Fix smbfs_node_alloc() cleanup on insmntque() failure
smbfs_node_alloc() leaks np->n_rpath and np->n_name on the insmntque()
failure path. I tested this on FreeBSD 14.4-RELEASE, but the affected code
path does not appear to be specific to this version.
bug #265148, comment #2 discussed a related situation. That reasoning is
correct for the vfs_hash_insert() failure path. However, before insmntque()
calls vgone(), vp->v_op has already been changed to dead_vnodeops. Therefore,
VOP_RECLAIM resolves to VOP_NULL rather than smbfs_reclaim(), and the resources
owned by np are not reclaimed on this path.
I tested this in a FreeBSD 14.4-RELEASE amd64 QEMU VM using fault injection
that temporarily sets MNTK_UNMOUNT | MNTK_UNMOUNTF before calling insmntque(),
forcing the real insmntque1_int() EBUSY path.
After the failed mount, vmstat -m showed:
Type Use Memory Req Size(s)
smbufs_node 0 0 1 256
smbufs_nname 2 32 2 16
This shows that np was freed, but the two M_SMBNODENAME allocations,
np->n_rpath and np->n_name, remained active.
I also tested the vfs_hash_insert() duplicate-vnode path separately. That path
does not appear to leak, because vfs_hash_insert() calls vgone(vp) while
vp->v_op is still smbfs_vnodeops, so smbfs_reclaim() runs and frees the smbnode
resources. Repeated forced vfs_hash_insert() duplicate insertions increased the
Req counters but did not increase the active Use counters. After unmount, both
smbufs_node and smbufs_nname Use returned to zero.
Thus, cleanup is necessary when insmntque() fails.
--
You are receiving this mail because:
You are the assignee for the bug.
