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, 23 May 2023 11:28:14 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Dan Carpenter <dan.carpenter@...aro.org>
Cc:     Naresh Kamboju <naresh.kamboju@...aro.org>,
        "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>,
        Will Deacon <will@...nel.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

On Mon, May 22, 2023 at 06:40:59PM +0300, Dan Carpenter wrote:
> On Thu, May 18, 2023 at 10:52:31AM +0900, Mark Brown wrote:

> > > When we call sme_alloc() it will say the buffer is already allocated
> > > and just zero out what we need for "vl", but the existing buffer is too
> > > small.

> > If we are setting the SVE vector length we do not need to reallocate the
> > SME state since the size of the data stored in the sme_state buffer is
> > influenced only by the SME vector length, not the SVE vector length.  We
> > unconditionally free the SVE state (causing it to be reallocated when
> > needed) since the size needed for it depends on both vector lengths.

> arch/arm64/kernel/fpsimd.c
>    909          /*
>    910           * Force reallocation of task SVE and SME state to the correct
>    911           * size on next use:
>    912           */
>    913          sve_free(task);

> Sure, this forces a reallocation.  But what prevents it from happening
> before we reach the task_set_vl() line?

Reallocation is either triggered by a trap from userspace or via ptrace,
as is a vector length configuration.  The two cases should already be
prevented from running simultaneously, and can't simultaneously perform
two actions.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)