linux-kernel - Re: arm64: perf test 26 rpi4 oops

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230731104340.GA24767@willie-the-truck>
Date:   Mon, 31 Jul 2023 11:43:40 +0100
From:   Will Deacon <will@...nel.org>
To:     Mike Galbraith <efault@....de>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>, lstoakes@...il.com,
        wangkefeng.wang@...wei.com, catalin.marinas@....com,
        ardb@...nel.org
Subject: Re: arm64: perf test 26 rpi4 oops

[+Lorenzo, Kefeng and others]

On Sun, Jul 30, 2023 at 06:09:15PM +0200, Mike Galbraith wrote:
> On Fri, 2023-07-28 at 15:18 +0100, Will Deacon wrote:
> >
> > Looking at this quickly with Mark, the most likely explanation is that
> > a bogus kernel address is being passed as the source pointer to
> > copy_to_user().
> 
> 'start' in read_kcore_iter() is bogus a LOT when running perf test 26,
> and that back to at least 5.15.  Seems removal of bogon-proofing gave a
> toothless old bug teeth, but seemingly only to perf test 26.  Rummaging
> around with crash vmlinux /proc/kcore seems to be bogon free anyway.
> 
> Someone should perhaps take a peek at perf.  Bogons aside, it also
> doesn't seem to care deeply about kernel response.  Whether the kernel
> oops or I bat 945 bogons aside, it says 'OK'.  That seems a tad odd.

Aha, so I think I triggered the issue you're seeing under QEMU (log
below). perf (unhelpfully) doesn't have stable test numbers, so it's
test 21 in my case. However, it only explodes if I run it as root, since
/proc/kcore is 0400 on my system.

The easiest way to trigger the problem is simply:

# objdump -d /proc/kcore

Looking at the history, I wonder whether this is because of a combination
of:

e025ab842ec3 ("mm: remove kern_addr_valid() completely")

which removed the kern_addr_valid() check on the basis that kcore used
copy_from_kernel_nofault() anyway, and:

2e1c0170771e ("fs/proc/kcore: avoid bounce buffer for ktext data")

which replaced the copy_from_kernel_nofault() with _copy_to_user().

So with both of those applied, we're missing the address check on arm64.

Will

--->8

[   40.136085] Unable to handle kernel paging request at virtual address ffffffdcaabf0000
[   40.136453] Mem abort info:
[   40.136570]   ESR = 0x0000000096000006
[   40.136737]   EC = 0x25: DABT (current EL), IL = 32 bits
[   40.136946]   SET = 0, FnV = 0
[   40.137085]   EA = 0, S1PTW = 0
[   40.137232]   FSC = 0x06: level 2 translation fault
[   40.137441] Data abort info:
[   40.137573]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[   40.137801]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   40.138005]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   40.138257] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000e51c5000
[   40.138516] [ffffffdcaabf0000] pgd=100000023ffff003, p4d=100000023ffff003, pud=100000023ffff003, pmd=0000000000000000
[   40.139218] Internal error: Oops: 0000000096000006 [#1] SMP
[   40.139515] Modules linked in:
[   40.139780] CPU: 1 PID: 225 Comm: objdump Not tainted 6.5.0-rc3-v8 #5
[   40.140038] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[   40.140439] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   40.140710] pc : __arch_copy_to_user+0x180/0x240
[   40.140944] lr : _copy_to_iter+0xe8/0x4b0
[   40.141115] sp : ffffffc0805b3950
[   40.141256] x29: ffffffc0805b3950 x28: ffffffdcaabf0000 x27: ffffffdcabfff228
[   40.141568] x26: ffffffdcaabf0000 x25: ffffffc0805b3d68 x24: 0000000000000001
[   40.141841] x23: ffffff80c0e2d880 x22: ffffffc0805b3d40 x21: 0000000000000400
[   40.142119] x20: ffffffdcabe9cd40 x19: 0000000000000400 x18: 0000000000000000
[   40.142385] x17: 0000000000000000 x16: 0000000000000000 x15: ffffffdcaabf0000
[   40.142665] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[   40.142933] x11: 0000008000000000 x10: ffffffdcabe9cd40 x9 : 0000000000000230
[   40.143206] x8 : 0000000000101000 x7 : 0000007e08000000 x6 : 00000055c51a9840
[   40.143479] x5 : 00000055c51a9c40 x4 : 0000000000000000 x3 : 0000000000000400
[   40.143761] x2 : 0000000000000380 x1 : ffffffdcaabf0000 x0 : 00000055c51a9840
[   40.144124] Call trace:
[   40.144258]  __arch_copy_to_user+0x180/0x240
[   40.144433]  read_kcore_iter+0x718/0x810
[   40.144564]  proc_reg_read_iter+0x8c/0xe8
[   40.144720]  vfs_read+0x204/0x2a8
[   40.144846]  ksys_read+0x74/0x108
[   40.144975]  __arm64_sys_read+0x24/0x38
[   40.145113]  invoke_syscall+0x4c/0x118
[   40.145267]  el0_svc_common.constprop.0+0x68/0x120
[   40.145437]  do_el0_svc+0x40/0xa8
[   40.145568]  el0_svc+0x30/0x98
[   40.145702]  el0t_64_sync_handler+0xc0/0xc8
[   40.145866]  el0t_64_sync+0x190/0x198
[   40.146103] Code: d503201f d503201f d503201f d503201f (a8c12027) 
[   40.146518] ---[ end trace 0000000000000000 ]---