[LTS 8.6] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm

[pvts-mat]

CVE-2022-42896
VULN-204

Solution

The bug fix in the mainline is provided¹ in two commits:

• f937b758a188d6fd328a81367087eddbb2fce50f
• 711f8c3fb3db61897080468586b970c87c61d9e4

Of these the 711f8c3 is already applied on ciqlts8_6 (commit 8b3cab2c7776120fdd10fc27fb983f706b32808a).

(Same situation as in #41)

Build

Kernel built on virtual machine instantiated on physical Rocky 9 machine with

./ninja.sh _run_build-ciqlts8_6

from the https://gitlab.conclusive.pl/devices/rocky-patching project. Installed on a testing machine created with

CVE=CVE-2022-42896 ./ninja.sh _run_test-ciqlts8_6-CVE-2022-42896

Logs: build.log

kABI check: passed

kABI check ran on the build machine with

python3 /mnt/code/kernel-dist-git/SOURCES/check-kabi \
        -k /mnt/code/kernel-dist-git/SOURCES/Module.kabi_$(uname -m) \
        -s /mnt/build_files/kernel-src-tree-ciqlts8_6-CVE-2022-42896/Module.symvers

for the /mnt/code/kernel-dist-git repo in the state of

On branch el-8.6
Your branch is up to date with 'origin/el-8.6'.

commit hash 9cb8f01815976c24b697b25ddc56b4695747de9b.

Boot test: passed

boot-test.log

Kselftests: passed relative

Kselftests were split into two parts:

1. using kernel-selftests-internal package (for ease of use and stability of the tests) and
2. using kselftests compiled from kernel source (for coverage).

The set of tests covered by each method do not overlap. The chosen policy was "if a test exists in kernel-selftests-internal then use this implementation, otherwise use source-compiled one". This should provide best possible tests stability and coverage.

Packaged tests

Tests set covered

• bpf
• livepatch
• net
• net/forwarding
• net/mptcp
• netfilter
• tc-testing

Packgae

The package is not available in repositories for Rocky 8.6 and before the latest commit 6c475c05370eb88e87cfe3df4463ef461483e908 successful rpm build was impossible due to a bug in clang. The rpm package was custom built using kernel-dist-git project (9cb8f01815976c24b697b25ddc56b4695747de9b) with kernel source from ciqlts8_6 (6c475c05370eb88e87cfe3df4463ef461483e908) and made available at https://gitlab.conclusive.pl/devices/rocky-patching/-/blob/master/kernel-selftests-internal-4.18.0-372.32.1.el8.0.7.x86_64.rpm?ref_type=heads

Tests results

1. Patched kernel

   kselftests–rpm–ciqlts8_6-CVE-2022-42896.zip

   Flat text file form:
   kselftests–rpm–ciqlts8_6-CVE-2022-42896.log

2. Reference kernel 6c475c05370eb88e87cfe3df4463ef461483e908

   kselftests–rpm–ciqlts8_6.zip

   Flat text file form:
   kselftests–rpm–ciqlts8_6.log

3. Summary

   The patched and reference tests results are identical

Source-compiled tests

Tests set covered

• android
• breakpoints
• capabilities
• core
• cpu-hotplug
• cpufreq
• efivarfs
• exec
• filesystems
• firmware
• fpu
• futex
• intel_pstate
• ipc
• kcmp
• kvm
• lib
• membarrier
• memory-hotplug
• mount
• nsfs
• proc
• pstore
• ptrace
• rtc
• sgx
• sigaltstack
• size
• splice
• static_keys
• sync
• sysctl
• timens
• timers
• tpm2
• user
• vm
• x86
• zram

Tests results

1. Patched kernel

   kselftests–kernel-src–ciqlts8_6-CVE-2022-42896.log

2. Reference kernel 6c475c05370eb88e87cfe3df4463ef461483e908

   kselftests–kernel-src–ciqlts8_6.log

3. Summary

   The only status difference between patch and reference is for the ipc:msgque test. This test was found to be "flappy" (along with netfilter:nft_flowtable.sh and net:xfrm_policy.sh) in the course of 4 different runs on the same reference kernel. See column https://docs.google.com/spreadsheets/d/1tUwJ2rV57cYZXh7momPtraSjZcHDjMYHLeHA3DYWrUU/edit?gid=0#gid=0&range=C:C for the summary of tests behavior for Rocky 8.6 found so far.

Additional tests: none

Following the guidelines from the precedent #41.

Footnotes

¹ GHSA-pf87-6c9q-jvm4

[gvrose8192]

Looks similar to the previous fix in this series for CVE-2022-42896 - Thanks!

[pvts-mat]

Looks similar to the previous fix in this series for GHSA-pvw8-76h2-7q32 - Thanks!

Right, this CVE became basically an exercise in Rocky testing, which turned out to be much more involved than one could have thought. I'm experimenting with different approaches and trying to find a way to automate it, manual logs diffing is just horrible, not to even mention the indeterministic results...

[PlaidCat]