linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb+git@google.com>
To: linux-hardening@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,  Ard Biesheuvel <ardb@kernel.org>,
	Kees Cook <kees@kernel.org>, Ryan Roberts <ryan.roberts@arm.com>,
	 Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Jeremy Linton <jeremy.linton@arm.com>,
	 Catalin Marinas <Catalin.Marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	 "Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: [RFC/RFT PATCH 5/6] random: Plug race in preceding patch
Date: Thu, 27 Nov 2025 10:22:32 +0100	[thread overview]
Message-ID: <20251127092226.1439196-13-ardb+git@google.com> (raw)
In-Reply-To: <20251127092226.1439196-8-ardb+git@google.com>

From: Ard Biesheuvel <ardb@kernel.org>

The lockless get_random_uXX() reads the next value from the linear
buffer and then overwrites it with a 0x0 value. This is racy, as the
code might be re-entered by an interrupt handler, and so the store might
redundantly wipe the location accessed by the interrupt context rather
than the interrupted context.

To plug this race, wipe the preceding location when reading the next
value from the linear buffer. Given that the position is always non-zero
outside of the critical section, this is guaranteed to be safe, and
ensures that the produced values are always wiped from the buffer.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 drivers/char/random.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 71bd74871540..e8ba460c5c9c 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -547,6 +547,7 @@ type get_random_ ##type(void)							\
 	next = (u64)next_gen << 32;						\
 	if (likely(batch->position < ARRAY_SIZE(batch->entropy))) {		\
 		next |=	batch->position + 1; /* next-1 is bogus otherwise */	\
+		batch->entropy[batch->position - 1] = 0;			\
 		ret = batch->entropy[batch->position];				\
 	}									\
 	if (cmpxchg64_local(&batch->posgen, next, next - 1) != next - 1) {	\
-- 
2.52.0.107.ga0afd4fd5b-goog



  parent reply	other threads:[~2025-11-27  9:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-27  9:22 [RFC/RFT PATCH 0/6] Improve get_random_u8() for use in randomize kstack Ard Biesheuvel
2025-11-27  9:22 ` [RFC/RFT PATCH 1/6] hexagon: Wire up cmpxchg64_local() to generic implementation Ard Biesheuvel
2025-11-27  9:22 ` [RFC/RFT PATCH 2/6] arc: " Ard Biesheuvel
2025-11-27 15:06   ` Joey Gouly
2025-12-03 16:59     ` Ard Biesheuvel
2025-11-27  9:22 ` [RFC/RFT PATCH 3/6] random: Use u32 to keep track of batched entropy generation Ard Biesheuvel
2025-11-27 10:11   ` david laight
2025-11-27 10:15     ` Ard Biesheuvel
2025-11-27  9:22 ` [RFC/RFT PATCH 4/6] random: Use a lockless fast path for get_random_uXX() Ard Biesheuvel
2025-11-27 10:32   ` Ard Biesheuvel
2025-11-27  9:22 ` Ard Biesheuvel [this message]
2025-11-28 11:13   ` [RFC/RFT PATCH 5/6] random: Plug race in preceding patch david laight
2025-11-28 11:18     ` Ard Biesheuvel
2025-11-27  9:22 ` [RFC/RFT PATCH 6/6] randomize_kstack: Use get_random_u8() at entry for entropy Ard Biesheuvel
2025-11-27 12:12 ` [RFC/RFT PATCH 0/6] Improve get_random_u8() for use in randomize kstack Ryan Roberts
2025-11-27 12:28   ` Ard Biesheuvel
2025-11-27 13:08     ` Ryan Roberts
2025-11-27 14:18     ` Ryan Roberts
2025-11-27 15:03       ` Ard Biesheuvel
2025-11-27 15:40         ` Ard Biesheuvel
2025-11-27 15:56         ` Ryan Roberts
2025-11-27 16:58           ` Mark Rutland
2025-11-27 19:01             ` Ard Biesheuvel
2025-11-28 10:36               ` Ryan Roberts
2025-11-28 11:44                 ` Mark Rutland
2025-11-28 10:07           ` Ard Biesheuvel
2025-11-28 10:32             ` Ryan Roberts
2025-11-28 10:36               ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251127092226.1439196-13-ardb+git@google.com \
    --to=ardb+git@google.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=jeremy.linton@arm.com \
    --cc=kees@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ryan.roberts@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).