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: <43d53046-f8d9-4c4a-90ba-709910a13f97@kili.mountain>
Date:   Mon, 22 May 2023 18:40:59 +0300
From:   Dan Carpenter <dan.carpenter@...aro.org>
To:     Mark Brown <broonie@...nel.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 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?

   914          if (system_supports_sme() && type == ARM64_VEC_SME)
   915                  sme_free(task);
   916  
   917          task_set_vl(task, type, vl);
   918  
   919  out:
   920          update_tsk_thread_flag(task, vec_vl_inherit_flag(type),
   921                                 flags & PR_SVE_VL_INHERIT);
   922  
   923          return 0;

regards,
dan carpenter