linux-kernel - Re: arm64: fp-stress: BUG: KFENCE: memory corruption in fpsimd_release

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]

Date:   Tue, 16 May 2023 14:44:49 +0100
From:   Will Deacon <will@...nel.org>
To:     Naresh Kamboju <naresh.kamboju@...aro.org>, broonie@...nel.org
Cc:     "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        linux-stable <stable@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        lkft-triage@...ts.linaro.org,
        Catalin Marinas <catalin.marinas@....com>,
        Dan Carpenter <dan.carpenter@...aro.org>,
        Arnd Bergmann <arnd@...db.de>, Shuah Khan <shuah@...nel.org>,
        Anders Roxell <anders.roxell@...aro.org>
Subject: Re: arm64: fp-stress: BUG: KFENCE: memory corruption in
 fpsimd_release_task

Hi Naresh,

On Tue, May 16, 2023 at 11:58:40AM +0530, Naresh Kamboju wrote:
> Following kernel BUG noticed while running selftests arm64 fp-stress
> running stable rc kernel versions 6.1.29-rc1 and 6.3.3-rc1.

Is there a known-good build so that we could attempt a bisection?

> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> 
> # selftests: arm64: fp-stress
> # TAP version 13
> # 1..80
> # # 8 CPUs, 3 SVE VLs, 3 SME VLs, SME2 absent
> # # Will run for 10s
> ...
> 
> # # ZA-VL-32-4: PID: 1091
> # # [  263.834190]
> ==================================================================
> [  263.834270] BUG: KFENCE: memory corruption in fpsimd_release_task+0x28/0x50
> [  263.834270]
> ZA-V[  263.834419] Corrupted memory at 0x00000000d9c0a375 [ ! ! ! ! !
> ! . . . . . . . . . . ] (in kfence-#158):
> L-64-[  263.834929]  fpsimd_release_task+0x28/0x50
> [  263.835074]  arch_release_task_struct+0x1c/0x30
> [  263.835221]  __put_task_struct+0x164/0x220
> [  263.835336]  delayed_put_task_struct+0x60/0x128
> 4: [  263.835484]  rcu_core+0x318/0x950
> [  263.835632]  rcu_core_si+0x1c/0x30
> [  263.835770]  __do_softirq+0x110/0x3d8
> Stre[  263.835874]  run_ksoftirqd+0x40/0xe0
> [  263.835994]  smpboot_thread_fn+0x1d0/0x260
> [  263.836105]  kthread+0xec/0x190
> [  263.836221]  ret_from_fork+0x10/0x20
> [  263.836342]
> ami[  263.836393] kfence-#158: 0x00000000c8819329-0x000000009e00cc22,
> size=546, cache=kmalloc-1k
> [  263.836393]
> [  263.836527] allocated by task 1112 on cpu 5 at 252.422888s:
> [  263.836697]  do_sme_acc+0xa8/0x230
> ng m[  263.836821]  el0_sme_acc+0x40/0xa0
> [  263.836966]  el0t_64_sync_handler+0xa8/0xf0
> [  263.837114]  el0t_64_sync+0x190/0x198

Mark -- given that this is an SME allocation, please can you take a look?
I think the implication of the kfence report is that we're writing beyond
the end of 'task->thread.sme_state' at some point and corrupting the
redzone.

There are two reports here, so hopefully it's not too hard to repro.

Will