kernel/linux.git/drivers/char/ipmi, branch v6.19.11

ipmi:msghandler: Handle error returns from the SMI sender

2026-03-25T10:13:18+00:00

[ Upstream commit 62cd145453d577113f993efd025f258dd86aa183 ] It used to be, until recently, that the sender operation on the low level interfaces would not fail. That's not the case any more with recent changes. So check the return value from the sender operation, and propagate it back up from there and handle the errors in all places. Reported-by: Rafael J. Wysocki Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Reviewed-by: Rafael J. Wysocki (Intel) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ipmi: Consolidate the run to completion checking for xmit msgs lock

2026-03-25T10:13:18+00:00

[ Upstream commit 1d90e6c1a56f6ab83e5c9d30ded19e7ac8155713 ] It made things hard to read, move the check to a function. Signed-off-by: Corey Minyard Reviewed-by: Breno Leitao Stable-dep-of: 62cd145453d5 ("ipmi:msghandler: Handle error returns from the SMI sender") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ipmi:si: Fix check for a misbehaving BMC

2026-03-19T15:15:14+00:00

commit cae66f1a1dcd23e17da5a015ef9d731129f9d2dd upstream. There is a race on checking the state in the sender, it needs to be checked under a lock. But you also need a check to avoid issues with a misbehaving BMC for run to completion mode. So leave the check at the beginning for run to completion, and add a check under the lock to avoid the race. Reported-by: Rafael J. Wysocki Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Reviewed-by: Rafael J. Wysocki (Intel) Signed-off-by: Greg Kroah-Hartman

ipmi:si: Handle waiting messages when BMC failure detected

2026-03-19T15:15:13+00:00

commit 52c9ee202edd21d0599ac3b5a6fe1da2a2f053e5 upstream. If a BMC failure is detected, the current message is returned with an error. However, if there was a waiting message, it would not be handled. Add a check for the waiting message after handling the current message. Suggested-by: Guenter Roeck Reported-by: Rafael J. Wysocki Closes: https://lore.kernel.org/linux-acpi/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

ipmi:si: Use a long timeout when the BMC is misbehaving

2026-03-19T15:15:13+00:00

commit c3bb3295637cc9bf514f690941ca9a385bf30113 upstream. If the driver goes into HOSED state, don't reset the timeout to the short timeout in the timeout handler. Reported-by: Igor Raits Closes: https://lore.kernel.org/linux-acpi/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

ipmi:si: Don't block module unload if the BMC is messed up

2026-03-19T15:15:13+00:00

commit f895e5df80316a308c2f7d64d13a78494630ea05 upstream. If the BMC is in a bad state, don't bother waiting for queues messages since there can't be any. Otherwise the unload is blocked until the BMC is back in a good state. Reported-by: Rafael J. Wysocki Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Reviewed-by: Rafael J. Wysocki (Intel) Signed-off-by: Greg Kroah-Hartman

ipmi: Fix use-after-free and list corruption on sender error

2026-03-12T11:09:40+00:00

commit 594c11d0e1d445f580898a2b8c850f2e3f099368 upstream. 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 Closes: https://lore.kernel.org/lkml/20260127-ipmi-v1-0-ba5cc90f516f@debian.org/ Fixes: 9cf93a8fa9513 ("ipmi: Allow an SMI sender to return an error") Cc: stable@vger.kernel.org # 4.18 Reviewed-by: Breno Leitao Signed-off-by: Corey Minyard Signed-off-by: Breno Leitao Signed-off-by: Greg Kroah-Hartman

ipmi: ipmb: initialise event handler read bytes

2026-03-04T12:20:51+00:00

[ Upstream commit 9f235ccecd03c436cb1683eac16b12f119e54aa9 ] IPMB doesn't use i2c reads, but the handler needs to set a value. Otherwise an i2c read will return an uninitialised value from the bus driver. Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB") Signed-off-by: Matt Johnston Message-ID: <20260113-ipmb-read-init-v1-1-a9cbce7b94e3@codeconstruct.com.au> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

Merge tag 'for-linus-6.19-1' of https://github.com/cminyard/linux-ipmi

2025-12-06T04:49:24+00:00

Pull IPMI updates from Corey Minyard: "Minor IPMI fixes: - Some device tree cleanups and a maintainer add - Fix a race when handling channel updates that could result in errors being reported to the user in some cases" * tag 'for-linus-6.19-1' of https://github.com/cminyard/linux-ipmi: MAINTAINERS: Add entry on Loongson-2K IPMI driver dt-bindings: ipmi: Convert aspeed,ast2400-ibt-bmc to DT schema dt-bindings: ipmi: Convert nuvoton,npcm750-kcs-bmc to DT schema ipmi: Skip channel scan if channels are already marked ready ipmi: Fix __scan_channels() failing to rescan channels ipmi: Fix the race between __scan_channels() and deliver_response()

Merge tag 'printk-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux

2025-12-03T20:42:36+00:00

Pull printk updates from Petr Mladek: - Allow creaing nbcon console drivers with an unsafe write_atomic() callback that can only be called by the final nbcon_atomic_flush_unsafe(). Otherwise, the driver would rely on the kthread. It is going to be used as the-best-effort approach for an experimental nbcon netconsole driver, see https://lore.kernel.org/r/20251121-nbcon-v1-2-503d17b2b4af@debian.org Note that a safe .write_atomic() callback is supposed to work in NMI context. But some networking drivers are not safe even in IRQ context: https://lore.kernel.org/r/oc46gdpmmlly5o44obvmoatfqo5bhpgv7pabpvb6sjuqioymcg@gjsma3ghoz35 In an ideal world, all networking drivers would be fixed first and the atomic flush would be blocked only in NMI context. But it brings the question how reliable networking drivers are when the system is in a bad state. They might block flushing more reliable serial consoles which are more suitable for serious debugging anyway. - Allow to use the last 4 bytes of the printk ring buffer. - Prevent queuing IRQ work and block printk kthreads when consoles are suspended. Otherwise, they create non-necessary churn or even block the suspend. - Release console_lock() between each record in the kthread used for legacy consoles on RT. It might significantly speed up the boot. - Release nbcon context between each record in the atomic flush. It prevents stalls of the related printk kthread after it has lost the ownership in the middle of a record - Add support for NBCON consoles into KDB - Add %ptsP modifier for printing struct timespec64 and use it where possible - Misc code clean up * tag 'printk-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: (48 commits) printk: Use console_is_usable on console_unblank arch: um: kmsg_dump: Use console_is_usable drivers: serial: kgdboc: Drop checks for CON_ENABLED and CON_BOOT lib/vsprintf: Unify FORMAT_STATE_NUM handlers printk: Avoid irq_work for printk_deferred() on suspend printk: Avoid scheduling irq_work on suspend printk: Allow printk_trigger_flush() to flush all types tracing: Switch to use %ptSp scsi: snic: Switch to use %ptSp scsi: fnic: Switch to use %ptSp s390/dasd: Switch to use %ptSp ptp: ocp: Switch to use %ptSp pps: Switch to use %ptSp PCI: epf-test: Switch to use %ptSp net: dsa: sja1105: Switch to use %ptSp mmc: mmc_test: Switch to use %ptSp media: av7110: Switch to use %ptSp ipmi: Switch to use %ptSp igb: Switch to use %ptSp e1000e: Switch to use %ptSp ...