QA Regression test kernel-security reports two failures on 2.6.24-28.84 Xen

Bug #718839 reported by C de-Avillez on 2011-02-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

Build helper tools ... (8.04) ok
/proc/$pid/maps is correctly protected ... ok
ASLR enabled ... (skipped: boolean on Hardy and earlier) ok
ASLR of stack ... ok
ASLR of libs ... ok
ASLR of mmap ... ok
ASLR of text ... ok
ASLR of vdso ... ok
ASLR of brk ... (skipped: only Intrepid and later) ok
Low memory allocation respects mmap_min_addr ... ok
AppArmor loaded ... ok
PR_SET_SECCOMP works ... ok
/dev/kmem not available ... ok
SYN cookies is enabled ... (skipped: only Jaunty and later) ok
init's CAPABILITY list is clean ... ok
init missing READ_IMPLIES_EXEC ... (heap check) ok
NX bit is working ... ok
Userspace stack guard page exists (CVE-2010-2240) ... ok
CONFIG_COMPAT_BRK disabled ... ok
CONFIG_DEVKMEM disabled ... ok
CONFIG_SECURITY enabled ... ok
CONFIG_SYN_COOKIES enabled ... ok
CONFIG_SECCOMP enabled ... ok
CONFIG_COMPAT_VDSO disabled ... ok
CONFIG_DEBUG_SET_MODULE_RONX enabled ... (skipped: only Natty and later) ok
/dev/mem unreadable for kernel memory ... FAIL
CONFIG_SECURITY_FILE_CAPABILITIES enabled ... (skipped: only Intrepid through Lucid) ok
CONFIG_SECURITY_SMACK enabled ... (skipped: only Intrepid and later) ok
Kernel stack guard ... (skipped: only Karmic and later) ok
Sysctl to disable module loading exists ... (skipped: only Karmic and later) ok
Symlinks not followable across differing uids in sticky directories ... (skipped: only Maverick and later) ok
Hardlink disallowed for unreadable/unwritable sources ... (skipped: only Maverick and later) ok
PTRACE allowed only on children or declared processes ... (skipped: only Maverick and later) ok
Make sure rare network modules do not autoload ... (skipped: only Natty and later) ok
Make sure kernel addresses in kallsyms and modules are zeroed out ... (skipped: only Natty and later) ok
Make sure kernel addresses in /boot/ are not world readable ... (skipped: only Natty and later) ok

Traceback (most recent call last):
  File "./", line 518, in test_72_config_debug_rodata
    self.assertEqual(self._test_config('DEBUG_RODATA'), expected)
AssertionError: False != True

FAIL: /dev/mem unreadable for kernel memory
Traceback (most recent call last):
  File "./", line 585, in test_72_strict_devmem
    self.assertShellExitEquals(expected, ['./readmem'])
  File "/home/ubuntu/qrt-test-kernel/", line 648, in assertShellExitEquals
    self.assertEquals(expected, rc, msg + result + report)
AssertionError: Got exit code 4, expected 0
Command: './readmem'
0x1000 ... readable
0x2000 ... readable
0x4000 ... readable
0x8000 ... readable
0x10000 ... readable
0x20000 ... readable
0x40000 ... readable
0x80000 ... readable
0x100000 ... readable
0x200000 ... readable
0x400000 ... readable
0x800000 ... readable
0x1000000 ... readable
0x2000000 ... readable
0x4000000 ... readable
0x8000000 ... readable
0x10000000 ... readable
0x20000000 ... readable
0x40000000 ... readable
0x80000000 ... readable
0x100000000 ... readable
0x200000000 ... readable
0x400000000 ... readable
0x800000000 ... readable
0x1000000000 ... readable
0x2000000000 ... readable
0x4000000000 ... readable
0x8000000000 ... readable
0x10000000000 ... readable
0x20000000000 ... readable
0x40000000000 ... readable
0x80000000000 ... readable
0x100000000000 ... readable
0x200000000000 ... readable
0x400000000000 ... readable
0x800000000000 ... readable
0x1000000000000 ... missing, ran off end of physical memory
FAIL: scanned memory, got successful reads, and no EPERMs

Ran 42 tests in 5.262s

FAILED (failures=2)

C de-Avillez (hggdh2) on 2011-02-14
tags: added: qa
Kees Cook (kees) wrote :

I don't think these are regressions, but they're a delta from the regular hardy kernel. It might be interesting to try to fix DEBUG_RODATA (is it incompatible with Xen host patches?), and to get to the bottom of /dev/mem (again, something Xen-specific?). In the meantime, I can add a skip-check in the tests for hardy dom0, but I need to know how to identify the kernel from the standard kernel.

C de-Avillez (hggdh2) wrote :

It is interesting that 'uname -r' and 'cat /proc/version_signature' return different strings:

ubuntu@ubuntu:~$ cat /proc/version_signature
Ubuntu 2.6.24-4.6-generic
ubuntu@ubuntu:~$ uname -r

Shouldn't they be the same?

Jeremy Foshee (jeremyfoshee) wrote :

Hi C,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 718839

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Steve Beattie (sbeattie) wrote :

Marking confirmed (so that it won't get expired due to being marked incomplete) as it affects, and only affects hardy's -xen kernel.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Po-Hsu Lin (cypressyew) wrote :

Closing this bug with Won't fix as Hardy is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04)

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers