Re: FAILED: patch "[PATCH] ima: Avoid blocking in RCU read-side critical section" failed to apply to 6.6-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 24, 2024 at 8:06 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
> On Mon, 2024-06-24 at 18:47 +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> > The patch below does not apply to the 6.6-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@xxxxxxxxxxxxxxx>.
> >
> > To reproduce the conflict and resubmit, you may use the following commands:
> >
> > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
> > git checkout FETCH_HEAD
> > git cherry-pick -x 9a95c5bfbf02a0a7f5983280fe284a0ff0836c34
> > # <resolve conflicts, build, test, etc.>
> > git commit -s
> > git send-email --to '<stable@xxxxxxxxxxxxxxx>' --in-reply-to '2024062438-shaft-herbicide-4e7d@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
> >
> > Possible dependencies:
> >
> > 9a95c5bfbf02 ("ima: Avoid blocking in RCU read-side critical section")
> > 260017f31a8c ("lsm: use default hook return value in call_int_hook()")
> > 923831117611 ("evm: Move to LSM infrastructure")
> > 84594c9ecdca ("ima: Move IMA-Appraisal to LSM infrastructure")
> > cd3cec0a02c7 ("ima: Move to LSM infrastructure")
> > 06cca5110774 ("integrity: Move integrity_kernel_module_request() to IMA")
> > b8d997032a46 ("security: Introduce key_post_create_or_update hook")
> > 2d705d802414 ("security: Introduce inode_post_remove_acl hook")
> > 8b9d0b825c65 ("security: Introduce inode_post_set_acl hook")
> > a7811e34d100 ("security: Introduce inode_post_create_tmpfile hook")
> > f09068b5a114 ("security: Introduce file_release hook")
> > 8f46ff5767b0 ("security: Introduce file_post_open hook")
> > dae52cbf5887 ("security: Introduce inode_post_removexattr hook")
> > 77fa6f314f03 ("security: Introduce inode_post_setattr hook")
> > 314a8dc728d0 ("security: Align inode_setattr hook definition with EVM")
> > 779cb1947e27 ("evm: Align evm_inode_post_setxattr() definition with LSM infrastructure")
> > 2b6a4054f8c2 ("evm: Align evm_inode_setxattr() definition with LSM infrastructure")
> > 784111d0093e ("evm: Align evm_inode_post_setattr() definition with LSM infrastructure")
> > fec5f85e468d ("ima: Align ima_post_read_file() definition with LSM infrastructure")
> > 526864dd2f60 ("ima: Align ima_inode_removexattr() definition with LSM infrastructure")
>
> The patch doesn't apply cleanly due to the '0' in security_audit_rule_init():
>         return call_int_hook(audit_rule_init, 0, field, op, rulestr, lsmrule);
>
> Commit 260017f31a8c ("lsm: use default hook return value in call_int_hook()")
> removed it.  Instead of backporting commit 260017f31a8c, adding the '0' would be
> simpler.  This seems to be the only change needed for linux-6.8.y to 6.4.y.

Agreed.

> For linux-6.3.y to linux-6.2.y, commit b14faf9c94a6 ("lsm: move the audit hook
> comments to security/security.c") also needs to be applied.
>
> Paul, how do you normally handle backports?

Normally I just tag them accordingly and let the stable team handle
it, with the understanding that the stable team only picks patches
that have been explicitly marked for stable and not just anything with
a 'Fixes:' tag.  I'm sure you remember when we discussed this
recently, there shouldn't be anything new here.

The tricky part is what the patch fails to merge automatically.  It
has been my experience that the stable team really doesn't try to do
any manual merge fixups on the LSM, SELinux, or audit patches, so it
is really up to me or someone else who cares enough to do the backport
manually and resubmit.  See "option #3" in the stable kernel docs:

* https://docs.kernel.org/process/stable-kernel-rules.html#option-3

I've personally had some bad experiences working with the stable trees
(YMMV) which combined with a chronic lack of time means that I rarely
do a manual backport for the stable trees (the bug needs to be
especially horrendous).  However, others are always free to submit
backports, see the "option #3" link above.

-- 
paul-moore.com





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux