On Wed, Apr 02, 2025 at 05:15:44PM +0800, Wang Zhaolong wrote: > > On Wed, Apr 02, 2025 at 12:49:50PM +0800, Wang Zhaolong wrote: > > > Yes, it seems the previous description might not have been entirely clear. > > > I need to clearly point out that this patch, intended as the fix for CVE-2024-54680, > > > does not actually address any real issues. It also fails to resolve the null pointer > > > dereference problem within lockdep. On top of that, it has caused a series of > > > subsequent leakage issues. > > > > If this cve does not actually fix anything, then we can easily reject > > it, please just let us know if that needs to happen here. > > > > thanks, > > > > greg k-h > Hi Greg, > > Yes, I can confirm that the patch for CVE-2024-54680 (commit e9f2517a3e18) > should be rejected. Our analysis shows: > > 1. It fails to address the actual null pointer dereference in lockdep > > 2. It introduces multiple serious issues: > 1. A socket leak vulnerability as documented in bugzilla #219972 > 2. Network namespace refcount imbalance issues as described in > bugzilla #219792 (which required the follow-up mainline fix > 4e7f1644f2ac "smb: client: Fix netns refcount imbalance > causing leaks and use-after-free") > > The next thing we should probably do is: > - Reverting e9f2517a3e18 > - Reverting the follow-up fix 4e7f1644f2ac, as it's trying to fix > problems introduced by the problematic CVE patch Great, can you please send patches now for both of these so we can backport them to the stable kernels properly? > - Addressing the original lockdep issue properly (Kuniyuki is working > on a module ownership tracking patch, though it hasn't been merged yet) > > Regardless of the status of Kuniyuki's lockdep fix, the CVE patch itself > is fundamentally flawed and should be rejected as it creates more problems > than it solves. Ok, I'll go reject that now, thanks. greg k-h
