SECO-94 completion part 2

[bmastbergen]

Vulnerabilities and CVEs addressed include:

jira VULN-72
CVE-2021-4204

jira VULN-144
CVE-2022-23222

jira VULN-7854
CVE-2022-48929

build/install/boot log
kernel-build.log

[brett@vuln_72_8 ~]$ uname -a
Linux vuln_72_8 4.18.0-CVE-2021-4204+ #1 SMP Fri Nov 22 17:21:12 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

kselftests before and after
kernel-selftests-before.log
kernel-selftests-after.log

kselftests run with lockdep, kmemleak, and stress
kernel-selftests-stress-lockdep-kmemleak.log

The backported commits target bpf, so bpf specific kselftests before and after
bpf-selftests-before.log
bpf-selftests-after.log

Generally, I did what stable 5.15 did to address these two CVEs
https://lore.kernel.org/lkml/[email protected]/

Note: CVE-2022-48929 didn't have a ticket, but is a fix to a change made to address CVE-2022-0500. The backports referenced above folded this change into one of the 5 changes they made. I wanted to call out the change in its own commit. Thats why this PR has 6 commits, and stable only had 5

Note^: There was some discussion in PR #12 about how we ended up with a slightly different conditional in btf.c than what rocky8_10 has. That will be the case here as well. It seems like the backport of 45ce4b4 was not done correctly there. The conditional we end up with in this PR matches what is in current upstream.

Note^^: RH changelog would lead you to believe that c25b2ae addresses CVE-2022-0500 and CVE-2022-23222

• bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL (Viktor Malik) [RHEL-8473 RHEL-8476 RHEL-8925 RHEL-9037] {CVE-2022-0500 CVE-2022-23222}

But cvg.org references a different upstream commit as the fix for CVE-2022-23222
https://www.cve.org/CVERecord/?id=CVE-2022-23222
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=64620e0a1e712a778095bd35cbb277dc2259281f

This ^^^ is what I have backported to address CVE-2022-23222 and matches what stable did for 5.15

[PlaidCat]

Note^: There was some discussion in PR #12 about how we ended up with a slightly different conditional in btf.c than what rocky8_10 has. That will be the case here as well. It seems like the backport of 45ce4b4 was not done correctly there. The conditional we end up with in this PR matches what is in current upstream.

I think this was because I was looking at how the 553.16.1 kernel looked versus how the pre-req commit reorganized the code: bpf: Extend kfunc with PTR_TO_CTX, PTR_TO_MEM argument support cd19f9c

[PlaidCat]

Everything is looking pretty good.

Do we know if the following test just now work OR are the on the flappy list?

Thanks

[gvrose8192]

Everything is looking pretty good.

Do we know if the following test just now work OR are the on the flappy list?

Thanks

Wow - interesting. If those results are consistent that is a big fix.

[gvrose8192]

The code looks fine to me - Thanks!
I'd be very interested in how consistent the results are from the above bpf testing comments.

[gvrose8192]

LGTM - Thanks!

[bmastbergen]

Everything is looking pretty good.

Do we know if the following test just now work OR are the on the flappy list?

Thanks

I assumed that these are "flappy". But I guess I don't know for sure.

[bmastbergen]

Force pushed just to add reference to newly created VULN-7854 in the commit log

[PlaidCat]

Everything is looking pretty good.
Do we know if the following test just now work OR are the on the flappy list?

Thanks

I assumed that these are "flappy". But I guess I don't know for sure.

Do you still have the VM thats upgraded?
Could you rerun the test 5x to get a higher sample size?

I have a basic test I've been using for the releases by leveraging the built RPM for kernel-selftests-internal ... this should be pretty easy to transcribe to your BPF test execution

$ cat run_kerselftests.sh
#!/bin/bash

KENREL_VERSION=$(uname -r)

for i in $(seq 1 $1);
do
	echo "Starting Test Loop ${i}"
	sudo /usr/libexec/kselftests/run_kselftest.sh > /mnt/code/kernel_${KENREL_VERSION}_iteration_${i}.log
	echo "Test Loop ${i} Done"
	grep -v "^#" /mnt/code/kernel_${KENREL_VERSION}_iteration_${i}.log > /mnt/code/kernel_${KENREL_VERSION}_iteration_${i}_nocomments.log
done

[bmastbergen]

Everything is looking pretty good.
Do we know if the following test just now work OR are the on the flappy list?

Thanks

I assumed that these are "flappy". But I guess I don't know for sure.

Do you still have the VM thats upgraded? Could you rerun the test 5x to get a higher sample size?

I have a basic test I've been using for the releases by leveraging the built RPM for kernel-selftests-internal ... this should be pretty easy to transcribe to your BPF test execution

$ cat run_kerselftests.sh
#!/bin/bash

KENREL_VERSION=$(uname -r)

for i in $(seq 1 $1);
do
	echo "Starting Test Loop ${i}"
	sudo /usr/libexec/kselftests/run_kselftest.sh > /mnt/code/kernel_${KENREL_VERSION}_iteration_${i}.log
	echo "Test Loop ${i} Done"
	grep -v "^#" /mnt/code/kernel_${KENREL_VERSION}_iteration_${i}.log > /mnt/code/kernel_${KENREL_VERSION}_iteration_${i}_nocomments.log
done

I do have the vm so I can try. I actually ran the bpf tests out of the source tree, not with kernel-selftest-internal. Maybe I'll do a run of 5 both ways to see what shakes out