Re: Candidates for stable v6.9..v6.10-rc1 Use After Free

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, May 31, 2024 at 12:14:36AM -0400, Ronnie Sahlberg wrote:
> These commits reference use.after.free between v6.9 and v6.10-rc1
> 
> These commits are not, yet, in stable/linux-rolling-stable.
> Let me know if you would rather me compare to a different repo/branch.
> The list has been manually pruned to only contain commits that look like
> actual issues.
> If they contain a Fixes line it has been verified that at least one of the
> commits that the Fixes tag(s) reference is in stable/linux-rolling-stable
> 
> 
> 90e823498881fb8a91d8

Fun note, there are parts of the kernel, like is touched here, where
unless the commit is explicitly marked "for stable", we should not be
applying them.  Even if, as this changelog text says, "hey, this might
fix a bad thing."  We have to trust the maintainers here, sorry.

> 5c9c5d7f26acc2c669c1

Hey, a real one!

> 573601521277119f2e2b

Already in the tree as something else I think.

> f88da7fbf665ffdcbf5b

Again, amd gpu driver hell, already in the tree as a different commit.

> 47a92dfbe01f41bcbf35

fixes 6.10-rc1 stuff.

> 5bc9de065b8bb9b8dd87

Already merged.

> 5f204051d998ec3d7306

Another subsystem (XFS) that we are not allowed to touch.  The
maintainers will backport patches as needed and send them to us.  We
have a list of these types of files we need to ignore in the
stable-queue ignore_list file if you are curious.

> be84f32bb2c981ca6709

A real one!  Now queued up, thanks!

Note, the security/* files are famously almost never tagged for stable,
or have Fixes: markings on them.  I guess the security code must always
be secure that no fixes are ever needed... :)

> 88ce0106a1f603bf360c

Already in many releases.

thanks for the lists!

greg k-h