linux-kernel - Re: CVE-2025-22077: smb: client: Fix netns refcount imbalance causing leaks and use-after-free

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2025042111-provable-activism-ec0e@gregkh>
Date: Mon, 21 Apr 2025 08:49:04 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Wang Zhaolong <wangzhaolong1@...wei.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org
Subject: Re: CVE-2025-22077: smb: client: Fix netns refcount imbalance
 causing leaks and use-after-free

On Mon, Apr 21, 2025 at 10:59:47AM +0800, Wang Zhaolong wrote:
> 
> Given these findings, I recommend updating CVE-2025-22077 to reflect that the true fix
> is the reversion of e9f2517a3e18 (via commit 95d2b9f693ff).

Please do not top-post, it makes things impossible to quote properly :(

Anyway, I do not understand, sorry.  You are saying that commit
(95d2b9f693ff) is just reverting other attempts at fixing a bug, that
were not fixed properly.  So why would that commit be assigned a CVE if
the bugs were not being fixed properly?  What vulnerability does that
commit itself fix?

> > Dear CVE Community,
> > 
> > As the author of commit 4e7f1644f2ac ("smb: client: Fix netns refcount imbalance
> > causing leaks and use-after-free"), I want to clarify some confusion around the
> > proper fixes for these issues:
> > 
> > 1. Commit 4e7f1644f2ac is currently associated with CVE-2025-22077. However, this
> > patch was merely attempting to fix issues introduced by commit e9f2517a3e18 ("smb:
> > client: fix TCP timers deadlock after rmmod").

Did it not fix those issues?  If not, we can reject that CVE, please let
us know.

> > 2. As I've previously discussed with Greg Kroah-Hartman on the kernel mailing list[1],
> >     commit e9f2517a3e18 (which was intended to address CVE-2024-54680):
> >     - Failed to address the actual null pointer dereference in lockdep
> >     - Introduced multiple serious issues:
> >       - Socket leak vulnerability (bugzilla #219972)
> >       - Network namespace refcount imbalance (bugzilla #219792)

So this commit did not actually do anything?  If so, we can reject this
CVE.

> > 3. Our testing and analysis confirms that the original fix by Kuniyuki Iwashima,
> > commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace."), is
> > actually the correct approach. This patch properly handles network namespace
> > reference counting without introducing the problems that e9f2517a3e18 did.

But you say that commit is broken?

> > 4. The proper resolution for these issues was ultimately commit 95d2b9f693ff
> > ("Revert 'smb: client: fix TCP timers deadlock after rmmod'"), which reverted
> > the problematic patch. In the latest Linux mainline code, the problematic patch and
> > my subsequent fix patch have been reverted.[2][3]
> > 
> > Thank you for your attention to this matter. I'm happy to provide additional details if needed.

So, everything is now reverted and we are back at the beginning with the
original problem?

I'm sorry, but I really do not understand here what to do.  What exactly
are you wanting us to do?  Is the issue resolved?  If not, why not?  If
so, what commit fixed it?  Are there CVEs assigned to commits that are
not actually fixes?

totally confused,

greg k-h