dirtyc0w_shmem: Add minimum kernel version 6.0 check

[mananthu929]

The CVE 2022-2590 vulnerability applicable only on kernels 6.0 and above.
Add min_kver = "6.0" to skip the test on older kernels.

Test Module: vts_ltp_test_arm_64
Test Case: cve.cve-2022-2590_64bit#cve.cve-2022-2590_64bit
GBUG: 418679607

Signed-off-by: Madhu Ananthula [email protected]

[mananthu929]

BEFORE
Test Failed

AFTER (Ignored)

Execute the test case:
run vts -m vts_ltp_test_arm_64 -t cve.cve-2022-2590_64bit#cve.cve-2022-2590_64bit -l VERBOSE

Test case is IGNORED.

[c7aaf7e0] Starting arm64-v8a vts_ltp_test_arm_64 with 1 test

09-24 16:16:17 I/ConsoleReporter: [1/1 arm64-v8a vts_ltp_test_arm_64 c7aaf7e0] cve.cve-2022-2590_64bit#cve.cve-2022-2590_64bit ignore

=============== Results ==================

=============== Consumed Time ==============

arm64-v8a vts_ltp_test_arm_64: 8s

Total aggregated tests run time: 8s

============== TOP 1 Slow Modules ==============

arm64-v8a vts_ltp_test_arm_64: 0.12 tests/sec [1 tests / 8537 msec]

============== Modules Preparation Times ==============

arm64-v8a vts_ltp_test_arm_64 => prep = 346154 ms || clean = 8313 ms

Total preparation time: 5m 46s || Total tear down time: 8s

=======================================================

=============== Summary ===============

Total Run time: 7m 24s

1/1 modules completed

Total Tests : 1

PASSED : 0

FAILED : 0

IGNORED : 1

============== End of Results =============

[pevik]

FYI, you get much more attention in ML, as you did before https://lore.kernel.org/ltp/[email protected]/.

The CVE 2022-2590 vulnerability applicable only on kernels 6.0 and above.
Add min_kver = "6.0" to skip the test on older kernels.

According to CVE description the affected versions are 5.16-5.19.6, because it fixes a bug 9ae0f87d009ca ("mm/shmem: unconditionally set pte dirty in mfill_atomic_install_pte") from kernel v5.16-rc1. I.e. your original approach to require kernel v5.16 was better. (I was wrong on ML asking for 6.0). But would it harm to run it on older kernels?

[mananthu929]

But would it harm to run it on older kernels?

Hi @pevik Thanks for the comments.

-> your original approach to require kernel v5.16 was better. (I was wrong on ML asking for 6.0) sure will change the min_version from 6.0 -> 5.16
-> But would it harm to run it on older kernels? Google running the VTS tests on the system upgrading to new Google OS version (i.e. from Android 12 -> Android 14). Here kernel upgrade is not planned, system remains run on 5.4 kernel. hence we coud not integrate the patches recommend for this CVE.

Kindly confirm on the approval. will raise the New PR.

Thanks,

[pevik]

Google running the VTS tests on the system upgrading to new Google OS version (i.e. from Android 12 -> Android 14). Here kernel upgrade is not planned, system remains run on 5.4 kernel.

But in that case it should TCONF (which is not considered as a failure but as a skipped testing):

tst_test.c:2028: TINFO: Tested kernel: 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64
tst_kconfig.c:88: TINFO: Parsing kernel config '/boot/config-5.10.0-28-amd64'
tst_test.c:1846: TINFO: Overall timeout per run is 0h 02m 30s
dirtyc0w_shmem.c:54: TINFO: Mounting tmp_dirtyc0w_shmem to /tmp/LTP_dirZJBbXH/tmp_dirtyc0w_shmem fstyp=tmpfs flags=0
dirtyc0w_shmem_child.c:152: TCONF: System does not have userfaultfd minor fault support for shmem

IMHO we usually require minimal kernel version in a case when we cannot detect missing functionality. So I would keep it as is.

Hence we could not integrate the patches recommend for this CVE.

FYI LTP has (probably undocumented) policy do not hide bugs. It's not this case, but if some older kernel was vulnerable and cannot be fixed we don't want to hide it.

[mananthu929]

Hi @pevik , Thanks for the comments,

But what is the wayforward for cases like this? is this to be taken care by Google itself

Thanks,

[pevik]

But what is the wayforward for cases like this? is this to be taken care by Google itself

As I wrote, in my case on old kernel test exit with TCONF message: dirtyc0w_shmem_child.c:152: TCONF: System does not have userfaultfd minor fault support for shmem. min_version adds just a different TCONF message.

FYI the test works well on SLES 15-SP5 kernel based on 5.14. That is older than 5.16, which provided the fix. And I still consider good to run the test, even it should not be vulnerable for CVE-2022-2590 because the regression was brought later, it still get tested for the functionality (different backport can bring the same vulnerability).

Missing functionality (TCONF) is detected on SLES 15-SP3 kernel based on 5.3 (no need to set minimal kernel version). Also some Debian kernel 5.10 detect this TCONF.

Now I noted Test Failed in your original report. Could you please post the actual output of LTP test? It does not help when you post just messages from your framework which runs LTP. Also it would help if you provide also your kernel config. I suppose it's some missing kernel configuration which is required by the test. Because normally 5.4 should TCONF, not fail.

[pevik]

But what is the wayforward for cases like this? is this to be taken care by Google itself

I have no idea who supports your kernel (whether Google or Qualcomm or somebody else), that's a different question completely unrelated to LTP project.