While working on backporting the fix for CVE-2021-39686 in the Android-"version" of the 4.4.y kernel I noticed the missing cred_getsecid hook introduced in e.g. 4.19.y by 3ec30113264a7bcd389f51d1738e42da0f41bb5a

It seems the LSM security_* hooks haven't received updates for a while in this kernel. E.g. a source of error due to missed list HEAD init is due to 0302e28dee643932ee7b3c112ebccdbb9f8ec32c merging in 3dfc9b02864b19f4dab376f14479ee4ad1de6c9e which makes the HEAD initialization shorter and more reliable but trying to get that commit in results in quite a bit of merge conflicts as hooks have been added/removed in 4.19 which is not yet in 4.4.

Anyway: Are there any plans to synchronize the hooks in 4.4 with those in more recent kernels?

Regards,
Alexander

Hi!

While working on backporting the fix for CVE-2021-39686 in the
Android-"version" of the 4.4.y kernel I noticed the missing
cred_getsecid hook introduced in e.g. 4.19.y by
3ec30113264a7bcd389f51d1738e42da0f41bb5a (
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/commit/?h=linux-4.19.y&id=3ec30113264a7bcd389f51d1738e42da0f41bb5a
)

...

Anyway: Are there any plans to synchronize the hooks in 4.4 with those in more recent kernels?

Let me see. 4.19 has that commit; it was merged during merge
window. 4.9 does not have that commit.

If CVE-2021-39686 is important to you, right way forward would be to
backport neccessary changes to 4.9, first. We would rather not have
changes in 4.4-st that are not present in 4.9.X.

I don't think we have any plans to work in this area.

commit 3ec30113264a7bcd389f51d1738e42da0f41bb5a
Author: Matthew Garrett <mjg59@...>
Date: Mon Jan 8 13:36:19 2018 -0800

security: Add a cred_getsecid hook

For IMA purposes, we want to be able to obtain the prepared secid in the
bprm structure before the credentials are committed. Add a cred_getsecid
hook that makes this possible.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

If CVE-2021-39686 is important to you, right way forward would be to backport neccessary changes to 4.9, first. We would rather not have changes in 4.4-st that are not present in 4.9.X.

Hi Pavel, thanks for the reply.

I'm happy to contribute what I have back to 4.9. Can you give me some guidance on how I'd do that?
I've never contributed to the upstream kernel before but am confident in C/C++ and git and am maintaining an Android kernel fork.
In this case it should be pretty straight forward. All commits are from Googles android-mainline branch, backported where required, but mostly unchanged and I have the upstream discussions from the kernel ML for reference. If you are curious the 38 commits I want to backport to reduce the divergence and then fix that CVE can be found at https://github.com/Flamefire/android_kernel_sony_msm8998/pull/24.

It will likely be easy enough to port them to the 4.9 branch but I'd need to know how to have them applied and/or who to contact.

Best Regards,
Alex

PS: Greetings from Dresden, Germany

Hi!

If CVE-2021-39686 is important to you, right way forward would be to
backport neccessary changes to 4.9, first. We would rather not have
changes in 4.4-st that are not present in 4.9.X.

Hi Pavel, thanks for the reply.

I'm happy to contribute what I have back to 4.9. Can you give me some guidance on how I'd do that?
I've never contributed to the upstream kernel before but am confident in C/C++ and git and am maintaining an Android kernel fork.
In this case it should be pretty straight forward. All commits are from Googles android-mainline branch, backported where required, but mostly unchanged and I have the upstream discussions from the kernel ML for reference. If you are curious the 38 commits I want to backport to reduce the divergence and then fix that CVE can be found at https://github.com/Flamefire/android_kernel_sony_msm8998/pull/24.

It will likely be easy enough to port them to the 4.9 branch but I'd need to know how to have them applied and/or who to contact.

It should be enough to send them to stable@ mailing list, as described
in Documentation/process/stable-kernel-rules.rst . Greg KH (see
maintainers) is the person to talk to, but mailing list should be enough.

PS: Greetings from Dresden, Germany

Nice to meet you, Alex!

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany