grsecurity forums

Hi,

This is Archlinux with kernel 4.5.3 and grsec patch 201605080858.

Linux version 4.5.3.201605080858-1-grsec (builduser@strcat) (gcc version 6.1.1 20160501 (GCC) )

Here is what happens:

Code: Select all

PAX: size overflow detected in function track_pfn_insert arch/x86/mm/pat.c:961 cicus.328_21 max, count: 27, decl: lookup_memtype; num: 1; context: fndecl;
 CPU: 3 PID: 635 Comm: Xorg Not tainted 4.5.3.201605080858-1-grsec #1
 Hardware name: TOSHIBA SATELLITE Z30-B/SATELLITE Z30-B, BIOS Version 3.20   04/09/2015
  3ba7cd4a00000002 3ba7cd4afd24c243 0000000000000286 0000000000000000
  ffffc900012c3b00 ffffffff99311cbb 0000000000000008 3ba7cd4afd24c243
  ffffffff9991b4ab 00000000000003c1 ffffc900012c3b30 ffffffff991d8b14
 Call Trace:
  [<ffffffff99311cbb>] dump_stack+0x76/0xc3
  [<ffffffff991d8b14>] report_size_overflow+0x6c/0x80
  [<ffffffff990611a4>] track_pfn_insert+0x8c/0xb0
  [<ffffffff99172ead>] vm_insert_pfn+0x85/0x130
  [<ffffffffc0319f3c>] i915_gem_fault+0x3e4/0x5f0 [i915]
  [<ffffffff9916de66>] __do_fault+0xae/0x190
  [<ffffffff991735e9>] handle_mm_fault+0x491/0x1eb0
  [<ffffffff9905aa7c>] __do_page_fault+0x204/0x5d0
  [<ffffffff9905ae6a>] do_page_fault+0x22/0x40
  [<ffffffff9965bb38>] page_fault+0x28/0x30

The referenced function (if I got this right):

Code: Select all

int track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
                     pfn_t pfn)
{
        enum page_cache_mode pcm;

        if (!pat_enabled())
                return 0;

        /* Set prot based on lookup */
        pcm = lookup_memtype(pfn_t_to_phys(pfn));
        *prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
                         cachemode2protval(pcm));

        return 0;
}

The previous grsec patches worked fine (with an older kernel version).

If there's anything else I could add to help please ask.

Thanks.

Hi,

Could you please apply this patch and send me the result from dmesg?

Code: Select all

--- arch/x86/mm/pat.c.orig      2016-05-09 13:07:31.401623477 +0200
+++ arch/x86/mm/pat.c   2016-05-09 13:26:37.433638930 +0200
@@ -958,6 +958,7 @@
                return 0;
 
        /* Set prot based on lookup */
+       printk("PAX: pfn val: %llx\n", pfn.val);
        pcm = lookup_memtype(pfn_t_to_phys(pfn));
        *prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
                         cachemode2protval(pcm));


Hi,

I got this:

Code: Select all

PAX: pfn val: 20000000000e09ef
PAX: size overflow detected in function track_pfn_insert arch/x86/mm/pat.c:962 cicus.328_22 max, count: 27, decl: lookup_memtype; num: 1; context: fndecl;


I will do some more tests with my home laptop and let you know how it goes there.

Hi,

I ran into the same problem today.

Code: Select all

ArchLinux, linux-grsec-4.5.3.201605080858, gcc version 6.1.1 20160501 (GCC)

Code: Select all

Mai 09 16:56:21 fingerfalle kernel: PAX: pfn val: 20000000000e049e
Mai 09 16:56:21 fingerfalle kernel: PAX: size overflow detected in function track_pfn_insert arch/x86/mm/pat.c:962 cicus.347_22 max, count: 27, decl: lookup
Mai 09 16:56:21 fingerfalle kernel: CPU: 1 PID: 895 Comm: Xorg Tainted: G           O    4.5.3.201605080858-1-grsec-chron-mob #1
Mai 09 16:56:21 fingerfalle kernel: Hardware name: LENOVO 20AMS0SA08/20AMS0SA08, BIOS GIET84WW (2.34 ) 12/15/2015
Mai 09 16:56:21 fingerfalle kernel:  c8737a3100000002 c8737a319b83bc14 0000000000000286 0000000000000000
Mai 09 16:56:21 fingerfalle kernel:  ffffc90003a83b70 ffffffffb435b4db 00000000000002e2 c8737a319b83bc14
Mai 09 16:56:21 fingerfalle kernel:  ffffffffb499bb09 00000000000003c2 ffffc90003a83ba0 ffffffffb4214704
Mai 09 16:56:21 fingerfalle kernel: Call Trace:
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb435b4db>] dump_stack+0x76/0xc3
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb4214704>] report_size_overflow+0x6c/0x80
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb40643a2>] track_pfn_insert+0x7a/0xb0
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb41aba0d>] vm_insert_pfn+0x85/0x130
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffc0227b22>] i915_gem_fault+0x45a/0x6b0 [i915]
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb41a6966>] __do_fault+0xae/0x190
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb41ac149>] handle_mm_fault+0x491/0x1eb0
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb405d98c>] __do_page_fault+0x204/0x5d0
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb405dd7a>] do_page_fault+0x22/0x40
Mai 09 16:56:21 fingerfalle kernel:  [<ffffffffb46c31c8>] page_fault+0x28/0x30

I have the same issue when I try to compile the kernel with GCC version 6.1.1, with an older version (5.3.0) everything works normally.

It should be fixed in the patch just uploaded.

-Brad

so just for closure and future reference, here's the story on this one. there're two conditions for this false positive that in the end is due to a gcc induced intentional overflow. one's a kernel change in 4.5 that introduced the pfn_t type which encodes not only a pfn but also (ab)uses the MSBs as a sort of bitfield with accessor macros and whatnot. the other condition is gcc-6 itself whose cdcde pass (or thereabouts) apparently acquired some new smartness and can optimize out bitmasking operations if the masked bits would later be shifted out of the given type anyway (and it so happens that pfn_t is left shifted in the above code). now all this works out fine unless of course the whole operation takes place on the double wide integer type used by the size overflow plugin which will happily shift and thus preserve these MSBs in the double wide type and since gcc has already eliminated the bitmasking operation, we'll be left with an oversized value and thus the size overflow alert. the fix for this is unfortunately not at all easy for the same reasons that similar transformations in the frontend cannot be handled either, so for now we've just removed lookup_memtype from instrumentation.