linux-kernel - Re: Re: arm64: copy_from_user access the last page of ddr has problem on 4.14 kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Mon, 11 Feb 2019 11:34:46 +0000
From:   Will Deacon <will.deacon@....com>
To:     "kassey@....com" <kassey@....com>
Cc:     "kassey1216@...il.com" <kassey1216@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        willy <willy@...radead.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "catalin.marinas" <catalin.marinas@....com>,
        "mark.rutland" <mark.rutland@....com>,
        "robin.murphy" <robin.murphy@....com>,
        "ard.biesheuvel" <ard.biesheuvel@...aro.org>
Subject: Re: Re: arm64: copy_from_user access the last page of ddr has
 problem on 4.14 kernel

On Fri, Feb 01, 2019 at 05:46:44PM +0800, kassey@....com wrote:
>      sorry for late response. 
>      we did have process in userspace doing mmap. 
>      mult device can reprocued this issue, so we do not suspect the ddr
> not stable. 

Multiple devices of the same SoC?

>      can you help review  below patch to against with such issue, because
> we find if enable kasan , issue not seen.

Unfortunately, I'm not sure what more we can do with this unless we have a
reliable way to reproduce the problem. What is the output that you're
expecting to see in the page? You said that you're seeing the problem in
sel_write_load(), but afaict that /is/ dealing with binary policy data for
SELinux, which may well look like the corruption you describe.

Did you run memtest as I suggested?

Will
 
> The corruption you have is reasonably regular:
>  
> > 0079c00 6d6d 7061 0000 0000 0848 fd8f 0001 0000
> > 0079c10 0048 fd8f 0001 0000 0001 0000 0003 0000
> > 0079c20 2000 fd83 0001 0000 1fff fd86 0001 0000
> > 0079c30 0000 0000 0000 0000 700f 0000 0000 0000
>  
> Here's "mmap" again, but the record is twice as long:
>  
> > 0079c40 6d6d 7061 0000 0000 f448 ffff 0001 0000
> > 0079c50 f748 ffff 0001 0000 0001 0000 0004 0000
> > 0079c60 3000 fd8c 0001 0000 2fff fd8e 0001 0000
> > 0079c70 0000 0000 0000 0000 700f 0000 0000 0000
> > 0079c80 c103 0606 0100 be00 1009 3b00 3b07 0607
> > 0079c90 0100 5700 1006 e800 8c03 3103 0100 0a00
> > 0079ca0 0000 cf00 bf08 0a00 0100 5700 1006 3700
> > 0079cb0 3906 0606 0100 1600 0004 4700 9902 0207
>  
> And then the whole structure repeats:
>  
> > 0079cc0 6d6d 7061 0000 0000 f808 ffff 0001 0000
> > 0079cd0 f1c8 ffff 0001 0000 0001 0000 0005 0000
> > 0079ce0 d000 fff8 0001 0000 efff fffa 0001 0000
> > 0079cf0 0000 0000 0000 0000 700f 0000 0000 0000
>  
> > 0079d00 6d6d 7061 0000 0000 f1c8 ffff 0001 0000
> > 0079d10 f388 ffff 0001 0000 0001 0000 0003 0000
> > 0079d20 c000 ffdf 0001 0000 6fff fff8 0001 0000
> > 0079d30 0000 0000 0000 0000 700f 0000 0000 0000
> > 0079d40 9407 0901 0100 5300 0204 b400 d503 0a04
> > 0079d50 0100 0000 0001 0200 7309 0202 0100 0200
> > 0079d60 5000 0200 7309 0202 0400 ff00 f7ff 94ff
> > 0079d70 b400 0208 0100 dc00 0000 b400 5803 0607
> > 0079d80 6d6d 7061 0000 0000 f7c8 ffff 0001 0000