On Thu, Jun 1, 2023 at 11:51 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Jun 01, 2023 at 10:56:24AM -0400, Paul Moore wrote:
On Thu, Jun 1, 2023 at 9:20 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Jun 01, 2023 at 09:13:21AM -0400, Luiz Capitulino wrote:
...
Yes. I'm reporting this here because I'm more concerned with -stable kernels since they're more likely to be running on older user-space.
Yeah, we are bug-compatible! :)
While I really don't want to go back into the old arguments about what does, and does not, get backported to -stable, I do want to ask if there is some way to signal to the -stable maintainers that a patch should not be backported? Anything coming from the LSM, SELinux, or audit trees that I believe should be backported is explicitly marked with a stable@vger CC, as documented in stable-kernel-rules.rst, however it is generally my experience that patches with a 'Fixes:' tag are generally pulled into the -stable releases as well.
Really?
Yes, really.
Right now we HAVE to pick up the Fixes: tagged commits in those subsystems as you are missing lots of real fixes.
This starts to bring us back to the old argument about what is appropriate for -stable, but I've been sticking as close as possible to what is documented in stable-kernel-rules.rst which (ignoring things like HW enablement) advises that only patches which fix build issues or "serious issues" should be considered for -stable. I consider every bug fix that goes into the LSM, SELinux, and audit trees to see if it meets those criteria, if it does I mark it with a -stable tag, if not I leave the -stable tag and ensure it carries a 'Fixes:' tag if it makes sense and an appropriate root-cause commit is identified.
We definitely have different opinions on where the -stable bug fix threshold lies. I am of the opinion that every -stable backport carries risk, and I consider that when deciding if a commit should be marked for -stable. I do not believe that every bug fix, or every commit with a 'Fixes:' tag, should be backported to -stable.
I just quick looked and noticed 8cf0a1bc1287 ("capabilities: fix potential memleak on error path from vfs_getxattr_alloc()") which you should have tagged, right?
Nope. That's a memleak for a weird corner case that isn't really going to be triggered in practice; it was found only by code inspection and requires code modification to exercise. See the discussion around the original revision for more information:
https://lore.kernel.org/linux-security-module/20221025104544.2298829-1-cuiga...
Can you explain why you HAD to pick up that commit?
In fact, I've considered most of the LSM code as a "we never tag anything for stable so we rely on the Fixes: pickup to clean up after us" subsystem. We have many of those in the kernel, so you are in good company :)
That would be amusing if it were correct, but your use of absolutes betrays you. Looking at code under security/ from v5.10 to current on I see 71 -stable tags as of today. It looks like the last one I marked was from October of 2022. We could deep dive more on this, but I think that's a waste of everyone's time.
I could start dropping the 'Fixes:' tag from non-stable tagged commits, but that's a step backwards in my opinion.
If a commit has fixes: why wouldn't it be ok for stable trees? That feels very odd to me.
Backports have risk, and in my opinion not every bug fix rises to the level of severity to sufficiently counter that risk. The -stable kernel documentation seems to support that; if you believe every bug fix should be backported to the -stable kernels I would suggest you update the documentation.
Anyway, if you really want, yes, we can add you to the "list of subsystems we do not pick anything for except by explicit cc: stable marking" that we have, but note, that feels wrong to me based on the very low number of patches being tagged for these directories over time.
That's great, I didn't know you maintained such a list. Please add the LSM, SELinux, and audit trees to the subsystems which are only backported when there is an explicit -stable tag. It is worth noting that this should not affect the -stable backport policy for other LSMs, e.g. AppArmor, although I can mention this list to the other LSM maintainers as they may want to be added.