Database/Firmware, BMC & network fabric

ASPEED LPC control driver (drivers/soc/aspeed/aspeed-lpc-ctrl.c) in the OpenBMC kernel: A process on the BMC that can
Impact
A process on the BMC that can open the Aspeed LPC control device gets to mmap past the region it is supposed to own and write into BMC kernel memory. The size check compares the wrong quantities, so it is not a bounds check at all. The payoff is BMC root/kernel from a lower-privileged BMC daemon - which matters because OpenBMC's whole isolation story is that bmcweb, ipmid and the host-mailbox daemons run as separate constrained users. Chain it behind any of the bmcweb memory-corruption bugs and you go from a crashed web server to full control of the management processor, which is the position you need to write flash and persist.
Who can reach it
Local on the BMC itself. Requires code execution as a user with access to the LPC control character device - i.e. an attacker who already landed on the BMC via a network daemon bug, or a malicious/compromised OpenBMC package.
What to do
Kernel fix, landed in Linux 5.14.6 and backported. For an operator this is not a package update - the BMC kernel is baked into the firmware image, so it means a full BMC firmware flash per node, out-of-band, gated on your ODM rebasing their OpenBMC tree. Many ODM images sit years behind upstream. No config-only mitigation; the device node has to exist for host-BMC mailbox and flash-sharing features to work.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.