linux-kernel - Re: [PATCH 6.0 000/148] 6.0.19-rc1 review

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: <45e6c885-3035-4cd7-a4d0-69127814ef32@app.fastmail.com>
Date:   Wed, 11 Jan 2023 12:18:16 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Naresh Kamboju" <naresh.kamboju@...aro.org>
Cc:     "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, patches@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Guenter Roeck" <linux@...ck-us.net>, shuah@...nel.org,
        patches@...nelci.org, lkft-triage@...ts.linaro.org,
        "Pavel Machek" <pavel@...x.de>,
        "Jon Hunter" <jonathanh@...dia.com>,
        "Florian Fainelli" <f.fainelli@...il.com>,
        "Sudip Mukherjee" <sudipm.mukherjee@...il.com>,
        srw@...dewatkins.net, rwarsow@....de,
        "Mark Brown" <broonie@...nel.org>
Subject: Re: [PATCH 6.0 000/148] 6.0.19-rc1 review

On Wed, Jan 11, 2023, at 10:31, Naresh Kamboju wrote:
> On Wed, 11 Jan 2023 at 13:48, Arnd Bergmann <arnd@...db.de> wrote:
>> On Wed, Jan 11, 2023, at 07:16, Naresh Kamboju wrote:
>> > On Tue, 10 Jan 2023 at 23:36, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>
> Yes, it ran successfully on 6.0.18.
>
> On the same kernel 6.0.19-rc1 built with gcc-12 did not find this panic.
> The reported issue is specific to clang-15 build.

Ok, and was the 6.0.18 build using the exact same clang-15 toolchain,
or could there have been an update to any of the tools?

Have you seen results with older clang releases?

>> > [ 2893.044339] Insufficient stack space to handle exception!
>> > [ 2893.044351] ESR: 0x0000000096000047 -- DABT (current EL)
>> > [ 2893.044360] FAR: 0xffff8000128180d0
>> > [ 2893.044364] Task stack:     [0xffff800012a18000..0xffff800012a1c000]
>> > [ 2893.044370] IRQ stack:      [0xffff80000a798000..0xffff80000a79c000]
>> > [ 2893.044375] Overflow stack: [0xffff0000f77c4310..0xffff0000f77c5310]
>> ...
>> > [ 2893.044413] pc : el1h_64_sync+0x0/0x68
>> > [ 2893.044430] lr : wp_page_copy+0xf8/0x90c
>> > [ 2893.044445] sp : ffff8000128180d0
>> ...
>> > [ 2893.044646]  panic+0x168/0x374
>> > [ 2893.044658]  test_taint+0x0/0x38
>> > [ 2893.044667]  panic_bad_stack+0x110/0x124
>> > [ 2893.044675]  handle_bad_stack+0x34/0x48
>> > [ 2893.044685]  __bad_stack+0x78/0x7c
>> > [ 2893.044692]  el1h_64_sync+0x0/0x68
>> > [ 2893.044700]  do_wp_page+0x4a0/0x5c8
>> > [ 2893.044708]  handle_mm_fault+0x7fc/0x14dc
>> > [ 2893.044718]  do_page_fault+0x29c/0x450
>> > [ 2893.044727]  do_mem_abort+0x4c/0xf8
>> > [ 2893.044741]  el0_da+0x48/0xa8
>> > [ 2893.044750]  el0t_64_sync_handler+0xcc/0xf0
>> > [ 2893.044759]  el0t_64_sync+0x18c/0x190
>>
>> It claims that the stack overflow happened in do_wp_page(),
>> but that has a really short call chain. It would be good
>> to have the source line for do_wp_page+0x4a0/0x5c8 and
>> wp_page_copy+0xf8/0x90c to see where exactly it was.
>>
>> >   artifact-location:
>> > https://storage.tuxsuite.com/public/linaro/lkft/builds/2K9JDtix2mHMoYRjNkBef3oR5JT
>>
>
> Adding " / " at end works.
> https://storage.tuxsuite.com/public/linaro/lkft/builds/2K9JDtix2mHMoYRjNkBef3oR5JT/

Ok, I disassembled the image to see what happened.

do_wp_page+0x4a0/0x5c8 is the call to wp_page_copy(), so I would
guess the el1h_64_sync fault actually happened in that function.

lr : wp_page_copy+0xf8/0x90c the return address from
__mem_cgroup_charge(), but I suspect it's not where the fault
happened either, just the last address that was in the
link register.

el1h_64_sync+0x0/0x68 is a "paciasp" pointer authentication
instruction.

__bad_stack is actually called from 'vectors', which has this
code for calling el1h_64_sync, from kernel_ventry:

ffff800008011200:       d10543ff        sub     sp, sp, #0x150
ffff800008011204:       8b2063ff        add     sp, sp, x0
ffff800008011208:       cb2063e0        sub     x0, sp, x0
ffff80000801120c:       37700080        tbnz    w0, #14, ffff80000801121c <vectors+0x21c>
ffff800008011210:       cb2063e0        sub     x0, sp, x0
ffff800008011214:       cb2063ff        sub     sp, sp, x0
ffff800008011218:       14000201        b       ffff800008011a1c <el1h_64_sync>
ffff80000801121c:       d51bd040        msr     tpidr_el0, x0
ffff800008011220:       cb2063e0        sub     x0, sp, x0
ffff800008011224:       d51bd060        msr     tpidrro_el0, x0
ffff800008011228:       f0010a80        adrp    x0, ffff80000a164000 <overflow_stack+0xcf0>
ffff80000801122c:       910c401f        add     sp, x0, #0x310
ffff800008011230:       d538d080        mrs     x0, tpidr_el1
ffff800008011234:       8b2063ff        add     sp, sp, x0
ffff800008011238:       d53bd040        mrs     x0, tpidr_el0
ffff80000801123c:       cb2063e0        sub     x0, sp, x0
ffff800008011240:       f274cc1f        tst     x0, #0xfffffffffffff000
ffff800008011244:       54002de1        b.ne    ffff800008011800 <__bad_stack>  // b.any
ffff800008011248:       cb2063ff        sub     sp, sp, x0
ffff80000801124c:       d53bd060        mrs     x0, tpidrro_el0
ffff800008011250:       140001f3        b       ffff800008011a1c <el1h_64_sync>

and here I'm lost now.

      Arnd