test_021_aslr_dapper_libs (__main__.KernelASLRm32Tests)
ASLR of libs ... FAIL
test_021_aslr_dapper_mmap (__main__.KernelASLRm32Tests)
ASLR of mmap ... FAIL
test_022_aslr_hardy_vdso (__main__.KernelASLRm32Tests)
ASLR of vdso ... FAIL
test_021_aslr_dapper_libs (__main__.KernelASLRm32_CVE_2016_3672_Tests)
ASLR of libs ... FAIL
test_021_aslr_dapper_mmap (__main__.KernelASLRm32_CVE_2016_3672_Tests)
ASLR of mmap ... FAIL
test_022_aslr_hardy_vdso (__main__.KernelASLRm32_CVE_2016_3672_Tests)
ASLR of vdso ... FAIL
These tests (the gcc -m32 on amd64 versions) are all new to the QART tests in response to CVE-2016-3672, which is being addressed by the kernel in bug 1568523. The commit to fix CVE-2016-3672 (upstream 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb) was not incorporated in time for the 4.2.0-36.41 kernel.
With some hacky effort, I could adjust QART to not mark these as failures for the time being (and try to detect when they land via the kernel package changelog), but since the issue should be addressed in the next SRU cycle, I don't think this is a worthwhile effort. Do you concur?
All the failing tests from the log:
test_021_ aslr_dapper_ libs (__main_ _.KernelASLRm32 Tests) aslr_dapper_ mmap (__main_ _.KernelASLRm32 Tests) aslr_hardy_ vdso (__main_ _.KernelASLRm32 Tests) aslr_dapper_ libs (__main_ _.KernelASLRm32 _CVE_2016_ 3672_Tests) aslr_dapper_ mmap (__main_ _.KernelASLRm32 _CVE_2016_ 3672_Tests) aslr_hardy_ vdso (__main_ _.KernelASLRm32 _CVE_2016_ 3672_Tests)
ASLR of libs ... FAIL
test_021_
ASLR of mmap ... FAIL
test_022_
ASLR of vdso ... FAIL
test_021_
ASLR of libs ... FAIL
test_021_
ASLR of mmap ... FAIL
test_022_
ASLR of vdso ... FAIL
These tests (the gcc -m32 on amd64 versions) are all new to the QART tests in response to CVE-2016-3672, which is being addressed by the kernel in bug 1568523. The commit to fix CVE-2016-3672 (upstream 8b8addf891de8a0 0e4d39fc32f93f7 c5eb8feceb) was not incorporated in time for the 4.2.0-36.41 kernel.
With some hacky effort, I could adjust QART to not mark these as failures for the time being (and try to detect when they land via the kernel package changelog), but since the issue should be addressed in the next SRU cycle, I don't think this is a worthwhile effort. Do you concur?