From d8a33bc0a5d3b72ab6a0e7930345705e1d3d954b Mon Sep 17 00:00:00 2001 From: Richard Yao Date: Mon, 19 May 2025 13:04:05 -0400 Subject: [PATCH] icp: Use explicit_memset() exclusively in gcm_clear_ctx() d634d20d1be31dfa8cf06ef2dc96285baf81a2fb had been intended to fix a potential information leak issue where the compiler's optimization passes appeared to remove `memset()` operations that sanitize sensitive data before memory is freed for use by the rest of the kernel. When I wrote it, I had assumed that the compiler would not remove the other `memset()` operations, but upon reflection, I have realized that this was a bad assumption to make. I would rather have a very slight amount of additional overhead when calling `gcm_clear_ctx()` than risk a future compiler remove `memset()` calls. This is likely to happen if someone decides to try doing link time optimization and the person will not think to audit the assembly output for issues like this, so it is best to preempt the possibility before it happens. Reviewed-by: Brian Behlendorf Reviewed-by: Rob Norris Reviewed-by: Alexander Motin Reviewed-by: Jorgen Lundman Signed-off-by: Richard Yao Closes #17343 --- module/icp/algs/modes/modes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/module/icp/algs/modes/modes.c b/module/icp/algs/modes/modes.c index 3687131c5..343591cd9 100644 --- a/module/icp/algs/modes/modes.c +++ b/module/icp/algs/modes/modes.c @@ -173,12 +173,12 @@ gcm_clear_ctx(gcm_ctx_t *ctx) #if defined(CAN_USE_GCM_ASM) if (ctx->gcm_use_avx == B_TRUE) { ASSERT3P(ctx->gcm_Htable, !=, NULL); - memset(ctx->gcm_Htable, 0, ctx->gcm_htab_len); + explicit_memset(ctx->gcm_Htable, 0, ctx->gcm_htab_len); kmem_free(ctx->gcm_Htable, ctx->gcm_htab_len); } #endif if (ctx->gcm_pt_buf != NULL) { - memset(ctx->gcm_pt_buf, 0, ctx->gcm_pt_buf_len); + explicit_memset(ctx->gcm_pt_buf, 0, ctx->gcm_pt_buf_len); vmem_free(ctx->gcm_pt_buf, ctx->gcm_pt_buf_len); } /* Optional */