Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Michael Ellerman <patch-notifications@ellerman.id.au>
To:     Paul Mackerras <paulus@samba.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Christophe Leroy <christophe.leroy@csgroup.eu>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc:     Finn Thain <fthain@linux-m68k.org>, linuxppc-dev@lists.ozlabs.org,
        linux-kernel@vger.kernel.org, Stan Johnson <userm57@yahoo.com>
In-Reply-To: <0d0c4d0f050a637052287c09ba521bad960a2790.1631715131.git.christophe.leroy@csgroup.eu>
References: <0d0c4d0f050a637052287c09ba521bad960a2790.1631715131.git.christophe.leroy@csgroup.eu>
Subject: Re: [PATCH] powerpc/32s: Fix kuap_kernel_restore()
Message-Id: <163369938390.3568929.9026666512859787724.b4-ty@ellerman.id.au>
Date:   Sat, 09 Oct 2021 00:23:03 +1100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Wed, 15 Sep 2021 16:12:24 +0200, Christophe Leroy wrote:
> At interrupt exit, kuap_kernel_restore() calls kuap_unclok() with the
> value contained in regs->kuap. However, when regs->kuap contains
> 0xffffffff it means that KUAP was not unlocked so calling
> kuap_unlock() is unrelevant and results in jeopardising the contents
> of kernel space segment registers.
> 
> So check that regs->kuap doesn't contain KUAP_NONE before calling
> kuap_unlock(). In the meantime it also means that if KUAP has not
> been correcly locked back at interrupt exit, it must be locked
> before continuing. This is done by checking the content of
> current->thread.kuap which was returned by kuap_get_and_assert_locked()
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/32s: Fix kuap_kernel_restore()
      https://git.kernel.org/powerpc/c/d93f9e23744b7bf11a98b2ddb091d129482ae179

cheers