linux-kernel - Re: [PATCH v2] smb: client: Fix refcount leak for cifs_sb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAH2r5mvKpoaD3DDPAc=xUpbcF4TH4nedNdvZg6LBiETG5x3-DQ@mail.gmail.com>
Date: Thu, 16 Oct 2025 11:00:57 -0500
From: Steve French <smfrench@...il.com>
To: Markus Elfring <Markus.Elfring@....de>
Cc: Shuhao Fu <sfual@....ust.hk>, Steve French <sfrench@...ba.org>, linux-cifs@...r.kernel.org, 
	samba-technical@...ts.samba.org, Bharath SM <bharathsm@...rosoft.com>, 
	Paulo Alcantara <pc@...guebit.org>, Ronnie Sahlberg <ronniesahlberg@...il.com>, 
	Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>, 
	LKML <linux-kernel@...r.kernel.org>, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH v2] smb: client: Fix refcount leak for cifs_sb_tlink

The patch looks fine.  More important is focusing on the fixes (and
missing features) - minor wording of description can be helpful but
MUCH more important is focusing on xfstests, new test scenarios,
automated analysis to find places where use after frees possible etc,
fuzzing (like the great scripts Dr. Morris created for us to show some
potential security issues), fixing the various known bugs, adding the
missing features etc

On Thu, Oct 16, 2025 at 2:22 AM Markus Elfring <Markus.Elfring@....de> wrote:
>
> > Fix three refcount inconsistency issues related to `cifs_sb_tlink`.
>
> I find such an introduction sentence not so relevant here.
>
>
> > Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be
> > called after successful calls to `cifs_sb_tlink()`. Three calls fail to
> > update refcount accordingly, leading to possible resource leaks.
>
> * Can it be preferred to refer to the term “reference count”?
>
> * Would you find a description of corresponding case distinctions more helpful?
>
> * May resource leaks be indicated also in the summary phrase?
>
> * Would it be helpful to append parentheses to function names at more places?
>
> * Is there a need to mention change steps more individually?
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.17#n94
>
> * Will development interests grow for the application of scope-based resource management?
>
>
> Regards,
> Markus
>


-- 
Thanks,

Steve