Comment 4 for bug 734399

Revision history for this message
Kees Cook (kees) wrote :

We're faced with building new test cases when the kernels haven't been built yet, so in this case, I guessed wrong about which kernel version would fix the issue. This failure for 737676 should not be considered a regression. I will update the kernel version test.

    def test_093_ptrace_restriction_parent_via_thread(self):
        '''ptrace of child works from parent threads (LP: #737676)'''

        if self.lsb_release['Release'] < 10.10:
            self._skipped("only Maverick and later")
        expected = 0
        if self.lsb_release['Release'] == 10.10:
            if testlib.dpkg_compare_versions(self.kernel_version_ubuntu, 'le', '2.6.35-28.49') == 0:
                expected = 2

As for the amd64 heap/stack ASLR collision, what is "2.6.35-22.33-server/amd64"? The expected version (2.6.35-28.50-server/amd64) passes this test (as do 2.6.35-28.50-generic/amd64 2.6.35-28.50-generic/amd64 and 2.6.35-28.50-generic/amd64). Obviously that kernel version shouldn't be the one to be tested, so its failure is irrelevant.

Also why isn't the dbench failures of "2.6.35-28.50-generic/amd64 (KVM)" an issue? Note that http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/maverick-2.6.35-28.50-generic/kvm-amd64/test-dbench.txt is 404, as well as http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/maverick-2.6.35-28.50-generic/kvm-amd64/qrt-kernel-security.txt