From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 6E6CB19CD1D for ; Tue, 21 Apr 2026 13:25:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776777952; cv=none; b=qbDpv2RNzxGtMU4FiDKeOT5B6SutV9Rge65o+/Ag+0Y1XFlb+fWagysRE9kop1J6v30oAe0+TNj7N/aKc6r5fw1h+bXWk5bYFDzUukRsMhBKpoYSnrX5RNxmdNw9MQTWIXEV1iXeTjD63Ysb8uXR7/wPTrNSKFZdjK+uOpJ/5/o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776777952; c=relaxed/simple; bh=H39m+fbmGgI7CWitL7K+tYQciP4ZviiONiE0WoDN0aM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=m3BKs6CrnYsL+qQvNi+8mcV8PGmUBlra9bMnPimfSjO45WehT/AyHZnxqI2kYCydF20371DhLpsJneWsy2wlYftGAoMPZfgPFU3adlFTwls4AMqkaKdfiXdroT37ldmBbc7z8Xk+sKYiCxBb9o+MWIXjE0fgO2ykgzVTFspCv14= 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=cjzXZxsX; arc=none smtp.client-ip=209.85.167.175 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="cjzXZxsX" Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-464bc03efd8so2448857b6e.2 for ; Tue, 21 Apr 2026 06:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minyard.net; s=google; t=1776777950; x=1777382750; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=mSwCSc5fH6IwvCnImMYsVU3mZaN0tZTlBhr1KdpVNwA=; b=cjzXZxsXTqOCQAZE1UdBFsc/JkmYAgwwXRh1kyBM5x2mO0I/Sm/qtfJ1okazMNkR4d Wpbd+VDo/FEouyofk34XFD6MiWyX9N+bE27S2PlplJNCh7S0GNnoyoXSBbQY8nmYTvKk JD/Uaz5lzPjLFLFMX9hahkeOmavqWlO5e0ksNOn8Y+BKfy8X/vLAzHgoNSHtX0iW+93C /OldfYcG4aDJnqkwm2XV+cVUvpqORCA/LN3cGzJcCqYLhTgYZGjXY+2/N7q0JGfqZWaZ WPQdItjL0vacmb1/ba4wpVmGA1OpL6ytnc5KjbTmkqW6GUkNtfFsGNwQ8K1MlcN13rWH RJnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776777950; x=1777382750; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mSwCSc5fH6IwvCnImMYsVU3mZaN0tZTlBhr1KdpVNwA=; b=tMzMzz130eTV6KwUdg83AWJRvhIAGPjS3esn6a1+vt7X3hgCEtQ5aYnJhqZhCcrrzA briXp0KmhP0rLt/xVQG/Lpy6r6Fx8mDy0oYj6n5GBYwzvHaVRUnLUcx/SmcUFbEjd66u HFDEg+mAZgf1U/Shl2SIytoOedd0RllSeHqERM3jBuQDFsJGph2GdydGf6Dgs0OzWNNH g4+eROcu7D//8tFPXWNcGbkfB47PzDm5ybRzBm+tmLsurtfB2EpgHxVnxoeiOk4hhpDk W/eLd5iS8+nu1lFzBrkCS81A/GvGMSxq0ptS2limayVsIhgyDLvWC0evlJkdWpVJ1air tUZw== X-Forwarded-Encrypted: i=1; AFNElJ/W0Q6wMWar0WOY8dqsOUQF7K52n/OYKkFLi9RaZfYmB9Pf+RAe0H6SCor9AW2Kq2BuIyIh5qdEGCzyZ5w=@vger.kernel.org X-Gm-Message-State: AOJu0YzkjfnvQyb7emRuWkm02d2uVn6D+vz9EUVfb7/2dQtc5LwEodjT 7rE1eEP5WT98C07qh/lI0iodNH11g9BxRDTw0UAPjwQD5CMxl+fFIZw4Q9dzYen7c1w= X-Gm-Gg: AeBDiesW11hp1eCuAVviRfukgnWAXBe2eVcmrgpWikvTw+odvTgTNooTSVfi33SMRL2 51GXfDpE+lQD4pJyfFJZYZeyPMiZud1P577HMNE+7ZaS3/bTI5HAf1v2Bm8KEK/F9ThqO4m472K U4/dmMs6sAl36+x8m9I6wh+P2B96XBeN6HtK7MaiBAJsFjpsYXP9ALhvDCgTe/tJmzyEiTW9ml0 FlQbnD8v8gA/mEYKyec7GRSfeJq2Cje3GjwJCzgFDOTf4bLRUVFFnaaPARzz91ADeweBa2YF6oZ ObhpKj+ttyJQknUmlx3cX1yMMEmRJ1phGmzpmMDxlj9p2M6oEGjLZlN44/gznYWM0E51Mwf9YOc alyRdsiP8mYHDdPu4XNqFAO2v1xSWfpR/m+VDDi4POXnonUNmqELnx6jR3cc9rD4ZFCzqNA0Iml /+6wtieXRrPNJH3GmPJW2LGE8YBVtTkr2y3g5GfVl6Y+1lVZLZUdXLEjCzstqHv9rthWZbYj48m veZeCV6YKQbSM7V X-Received: by 2002:a05:6808:f87:b0:467:ea5:69b5 with SMTP id 5614622812f47-4799c989368mr9143525b6e.22.1776777950146; Tue, 21 Apr 2026 06:25:50 -0700 (PDT) Received: from localhost ([2001:470:b8f6:1b:376f:c507:59cb:4749]) by smtp.gmail.com with UTF8SMTPSA id 5614622812f47-479a03ac624sm9154889b6e.18.2026.04.21.06.25.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Apr 2026 06:25:49 -0700 (PDT) From: Corey Minyard To: Matt Fleming Cc: openipmi-developer@lists.sourceforge.net, Tony Camuso , linux-kernel@vger.kernel.org, kernel-team@cloudflare.com Subject: [PATCH 0/1] ipmi: Fix issues with BMCs that report event and message incorrectly Date: Tue, 21 Apr 2026 07:42:42 -0500 Message-ID: <20260421132544.2666174-1-corey@minyard.net> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Matt reported that there were issues with the IPMI driver getting wedged in some cases. It turns out that the BMC was not reporting an error as it should have (per the spec) when the event queue was empty. The IPMI driver would then request the next event, and so on, wedging the driver. The BMC sits on a fuzzy line between a trusted devices and a remote and possibly untrusted device. If you compromised a BMC you have all sorts of tools you can use to attack the host: the reset line, interrupts, and usually access to write the system firmware and possibly devices like disk drives, serial ports and VGA consoles. So attacking through this interface would not be the first thing you would do. But it is an possible attack point. I'm assuming that the BMC was delivering an empty message when this happens, so the first patch checks the message length to make sure it's a valid message. It's a good check no matter what, so it's in whether that's the issue or not. The second patch limits the number of events or messages that can be fetched at a time to 10. This is a good thing to do, anyway. If more message or events were present, the next flag check should get them. So it's a more general fix. I looked at adding the patch Matt suggested, doing a timeout on the wait, but that introduces some race conditions if the response comes back late. That will require some more thought. The timeouts with IPMI can be pretty long, the spec specifies fairly long timeouts, 5 seconds waiting for the BMC to respond to anything. So failing an operation can take some time, and reducing the timeouts is probably a bad idea. No rationale is given in the spec, but I'm guessing it expects that a BMC in restart can recover within 5 seconds, so it gives timeouts so the BMC is always available within that tie. The spec gives you the gist that the BMC should always be available on a system that has one. So the driver (at the beginning) followed that. Thus the driver tries 10 times for a message before it gives up, giving 50 seconds total failure time for a message. That is not in the spec (I don't think) so that could be made selectable on a per-message basis. There are already mechanisms for this available in the APIs; I'll look at that. -corey