From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A35E35B632 for ; Tue, 27 Jan 2026 13:59:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769522367; cv=none; b=g6CbLu6r5DJVqI+gVf34wrrUIIEu5NO+7t5y783AR1b5DqOKnUXgW9qtNFXIBDScF/ut3D14tg31Vn0pfpxOGTPe76SWfYdQjzMS3pwycRrMSFoXbUVefzxLwkeuHmN0du4Nf0RGoVMHTtBWUxbizr3fvcjNaE0EnR1JYRKHl/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769522367; c=relaxed/simple; bh=Sosu0g5xuLpMzNuU0oEuEsMP38OOZp79K3ER9Qyx7W0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LNpa5cUdbOc/xuaBKhXslNy9/r4ye49xXehMgt+M1Oa4/uXdFLeoJDur78yiut4H/P4mYvgisSjqUpLuDdBIg1dRzSWKaUlnFoYParyJMc1IWB8QNM232EBHeJoR8Dro0mrBwJBayHbqpbvq7+btTMJabBkl8n6QxDeyvg2cWrY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net; spf=pass smtp.mailfrom=minyard.net; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b=h2Nx6sul; arc=none smtp.client-ip=209.85.210.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=minyard.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b="h2Nx6sul" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7d1866473b0so204389a34.1 for ; Tue, 27 Jan 2026 05:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minyard.net; s=google; t=1769522365; x=1770127165; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wzzEevdAZzt1nXO9szlER+ciqn2pWS6swN7VnsinsFo=; b=h2Nx6sultJFUnppke+sGq1lIpUSVQoIKAi+tgV0LM6seIvKJ2itn05GN6nBCIzn9dz /83XUA+RTKdJdPKTb2TS8dA4wQfSOCs28WrRBuCZmtBwVow706GXzUz65HvSIaVyVkFn kOS7zVyi2SG6fC0oZ4UzkIyOXocO9BrzxFw4KvmrWI8eSNhgoIaDDbvQOCaoo60xwiFt 7lvnTTsHiEQkh+6Jqr034jvBsxC9m4h/zyGK7ixmLFEBaSryeFRO8vJB7EXdSO48uywz zk8EkbJu9n98Fs9AmgfHnHqXnmoJfjOBuOZjPLaleENi62vN2+KhAn0SIe3kZ66G35X0 oJ3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769522365; x=1770127165; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=wzzEevdAZzt1nXO9szlER+ciqn2pWS6swN7VnsinsFo=; b=m+2RnEgPqgdEta6l6K9VD3E4Xxshn4RFdlO475GOU1n7v5SdvclI6fHzdlRpHdsUx2 +CnZQMuFhYftocqxMjdDcJVsyEux8IfitqszvSbvSLAgFY43yb5YPb8juxYy+QdYRmBg oaBIo51uUr+TH4E6sIkWOQN0HN9Ko/6qE5NDIXn2MsbbsNnYfFHvS9zDcexC5yrb43FA SfDqVYpbZgi5ehKN4G3A/BNbcDfESCWHRmBpH67c0m6NLfyGdttlnRTHGwgbp7bGIogw C32419bM60nDMiYgOWixbfeuRmAF9nRBxVzyhEdb4WqEd/monei1n8INBK4dgtSKhrYz ZfsQ== X-Forwarded-Encrypted: i=1; AJvYcCWGWkc2a9AOfRAYfgddq52zJIdWmkyeVYxOWWqY5SCkkcOJMFYYzOtYQaG0p+8KuEaY0A7ZDo8JKq0n8tc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+I59gdRz+RjDOvOC6ea97v0LxX9TKJpKyktituQ5V9DTB83XR sJIm6XsiyXW9hkzZ8id7i8LG+uumtBztSipIWIdBbaZKvLXuUNEPTy5jbKNi+X02qHc= X-Gm-Gg: AZuq6aJv4ZR/IeewEdsFgC51yn1CNUoBq4Y23i9IWxEI2zn+CnHKlWZyxPmLfPsJbvB agNNf828WGeA/lVkpryypq7THec/luHLl7nEQWLbhgq3VijFeA6ApLZ4le4NfPmTJZqUO0RFChu 8oKI0ZCXG38lJzTTes/BPP4idqsLDWpzD8HNOME0yEcQovM0eSNc7lzDG6yvWLtlvz0cP9DWelF c56RD84ccb/9O/pf7FlVvpwsxYutpgBSZCHi9uJ7MXED+A25k4/HiqUfcOeKiBi+ZmpA2sgCusZ J+W/yPijFghIKzojutgVbks7h9dw1w8iFueZ7CGQ/S07QYXzTX3k4ExAZlY4IvlqsvWhSJY91kf p0AZp+gRwOK0DOd6zjP90sRqS/kogDZbaTSuKtZ2nVuHbvFVqOQkE92HSOx+hpCZDUpBI4eyEHX XH+/axee04wt+MSiIV5Gh5WPRMJtiflNyLLE1rP7NgKnwuBfzzvqSrJlp6CuWA/9N3TL8AVNfhB qWh X-Received: by 2002:a05:6830:4184:b0:7c7:6bb4:1197 with SMTP id 46e09a7af769-7d1850e6378mr1117433a34.24.1769522365402; Tue, 27 Jan 2026 05:59:25 -0800 (PST) Received: from localhost ([2001:470:b8f6:1b:a1a5:d807:e7a1:53eb]) by smtp.gmail.com with UTF8SMTPSA id 46e09a7af769-7d15b346e03sm9854283a34.1.2026.01.27.05.59.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 05:59:24 -0800 (PST) From: Corey Minyard To: Breno Leitao , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, kernel-team@meta.com, Corey Minyard Subject: [PATCH 1/2] ipmi: Fix use-after-free and list corruption on sender error Date: Tue, 27 Jan 2026 07:54:39 -0600 Message-ID: <20260127135917.1597762-2-corey@minyard.net> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260127135917.1597762-1-corey@minyard.net> References: <20260127-ipmi-v1-0-ba5cc90f516f@debian.org> <20260127135917.1597762-1-corey@minyard.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The analysis from Breno: When the SMI sender returns an error, smi_work() delivers an error response but then jumps back to restart without cleaning up properly: 1. intf->curr_msg is not cleared, so no new message is pulled 2. newmsg still points to the message, causing sender() to be called again with the same message 3. If sender() fails again, deliver_err_response() is called with the same recv_msg that was already queued for delivery This causes list_add corruption ("list_add double add") because the recv_msg is added to the user_msgs list twice. Subsequently, the corrupted list leads to use-after-free when the memory is freed and reused, and eventually a NULL pointer dereference when accessing recv_msg->done. The buggy sequence: sender() fails -> deliver_err_response(recv_msg) // recv_msg queued for delivery -> goto restart // curr_msg not cleared! sender() fails again (same message!) -> deliver_err_response(recv_msg) // tries to queue same recv_msg -> LIST CORRUPTION Fix this by freeing the message and setting it to NULL on a send error. Also, always free the newmsg on a send error, otherwise it will leak. Reported-by: Breno Leitao Fixes: 9cf93a8fa9513 ("ipmi: Allow an SMI sender to return an error") Signed-off-by: Corey Minyard --- drivers/char/ipmi/ipmi_msghandler.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index 3f48fc6ab596..a590a67294e2 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -4852,8 +4852,15 @@ static void smi_work(struct work_struct *t) if (newmsg->recv_msg) deliver_err_response(intf, newmsg->recv_msg, cc); - else - ipmi_free_smi_msg(newmsg); + if (!run_to_completion) + spin_lock_irqsave(&intf->xmit_msgs_lock, + flags); + intf->curr_msg = NULL; + if (!run_to_completion) + spin_unlock_irqrestore(&intf->xmit_msgs_lock, + flags); + ipmi_free_smi_msg(newmsg); + newmsg = NULL; goto restart; } } -- 2.43.0