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]

Message-ID: <ZGWE36pSRMsIHCCa@finisterre.sirena.org.uk>
Date:   Thu, 18 May 2023 10:52:31 +0900
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 Wed, May 17, 2023 at 10:30:29PM +0300, Dan Carpenter wrote:

> I don't know this code at all so probably this is dumb...  I don't
> undestand how vec_set_vector_length() ensures that sme_state_size()
> stays in sync with the actual size allocated in sme_alloc()

>    866          vl = find_supported_vector_length(type, vl);

> type is ARM64_VEC_SVE.  I've looked at this function for a while and
> I don't see anything which ensures that "vl" is less than the current
> value.

It could be either ARM64_VEC_SVE or ARM64_VEC_SME.

>    917          task_set_vl(task, type, vl);

> "vl" is set here.  This is fine if we are setting it to a smaller value,
> but if we are setting it to a larger value then I think we need to
> realloc the ->sme_state buffer.

> 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.

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