On Wed, Apr 02, 2025 at 01:50:05PM -0700, Kuniyuki Iwashima wrote: > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > Date: Wed, 2 Apr 2025 21:28:51 +0100 > > On Wed, Apr 02, 2025 at 01:22:11PM -0700, Kuniyuki Iwashima wrote: > > > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > > > Date: Wed, 2 Apr 2025 21:15:58 +0100 > > > > On Wed, Apr 02, 2025 at 01:09:19PM -0700, Kuniyuki Iwashima wrote: > > > > > From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > > > Date: Wed, 2 Apr 2025 16:18:37 +0100 > > > > > > 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? > > > > > > > > > > Sent to CIFS tree: > > > > > https://lore.kernel.org/linux-cifs/20250402200319.2834-1-kuniyu@xxxxxxxxxx/ > > > > > > > > You forgot to add a Cc: stable@ on the patches to ensure that they get > > > > picked up properly for all stable trees :( > > > > > > Ah sorry, I did the same with netdev. netdev patches usually do > > > not have the tag but are backported fine, maybe netdev local rule ? > > > > Nope, that's the "old" way of dealing with netdev patches, the > > documentation was changed years ago, please always put a cc: stable on > > it. Otherwise you are just at the whim of our "hey, I'm board, let's > > look for Fixes: only tags!" script to catch them, which will also never > > notify you of failures. > > Good to know that, thanks! > > My concern was that I could spam the list if I respin the patches, > and incomplete patch could be backported. > > >From stable-kernel-rules.rst, such an accident can be prevented if > someone points out a problem within 48 hours ? > > For example, if v1 is posted with Cc:stable, and a week later > v2 is posted, then the not-yet-upstreamed v1 could be backported ? > Anything can be asked to be applied to stable once it is in Linus's tree, but if you add the cc: stable stuff to the original patch, it will be done automatically for you. That's all, I don't see anything about "48 hours" in that document about submitting patches, that's only in the -rc review cycle portion of the stable releases, not Linus's releases. thanks, greg k-h
