linux-kernel - [PATCH 0/3] arm64/fpsimd: Fix use after free in SME when changing SVE VL

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-next>] [day] [month] [year] [list]

Message-Id: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@kernel.org>
Date:   Thu, 13 Jul 2023 21:06:03 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Shuah Khan <shuah@...nel.org>
Cc:     David Spickett <David.Spickett@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, Mark Brown <broonie@...nel.org>,
        stable@...r.kernel.org
Subject: [PATCH 0/3] arm64/fpsimd: Fix use after free in SME when changing
 SVE VL

This series fixes an issue which David Spickett found where if we change
the SVE VL while SME is in use we can end up attempting to save state to
an unallocated buffer and adds testing coverage for that plus a bit more
coverage of VL changes, just for paranioa.

Signed-off-by: Mark Brown <broonie@...nel.org>
---
Mark Brown (3):
      arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes
      kselftest/arm64: Add a test case for SVE VL changes with SME active
      kselftest/arm64: Validate that changing one VL type does not affect another

 arch/arm64/kernel/fpsimd.c                    |  32 +++++--
 tools/testing/selftests/arm64/fp/vec-syscfg.c | 127 +++++++++++++++++++++++++-
 2 files changed, 148 insertions(+), 11 deletions(-)
---
base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
change-id: 20230713-arm64-fix-sve-sme-vl-change-60eb1fa6a707

Best regards,
-- 
Mark Brown <broonie@...nel.org>