Fix heap-use-after-free in IntelCpuSensor::Reinitialize callback lifetime Concurrent Reinitialize() calls from a control thread could free an in-flight callback out from under the io_context thread. The callback was stored as a std::shared_ptr<absl::AnyInvocable> and Reinitialize() reassigned it directly on the *calling* thread (in production, SensorCollector::ReinitializeAndScheduleAllSensorsForConfigKey runs on a different thread than the sensor's io_context). The retry chain reads and invokes the callback via `std::move(*reinitialize_callback_)` on the io_context thread without holding its own reference (the signature is not &&-qualified, so the invocation does not consume the target). A second Reinitialize() reassigning the member therefore drops the last shared_ptr reference and frees the callback -- and its captures -- while the io_context thread is still reading/invoking it: a heap-use-after-free, reproducible under ASAN. Confine reinitialize_callback_ and attempt_num_ to the io_context thread: - Store the callback as a plain absl::AnyInvocable (no shared_ptr). - Reinitialize() posts all state mutation to the io_context thread and supersedes any active retry chain by cancelling the pending timer and completing the superseded callback with CancelledError before installing the new one. - The success path moves the callback into a local and clears the member before invoking it, so the end of a chain is well defined. - Aborted timer waits (operation_aborted) end the chain quietly instead of invoking a now-superseded callback. Add a regression test that reproduces the race under real production threading: a dedicated caller thread hammers Reinitialize() while the sensor's retry chain runs on the io_context thread. A bounded in-flight window keeps both threads overlapping without letting the work queue grow unboundedly. The test aborts with a heap-use-after-free under ASAN on the old implementation and passes with this fix. Google-Bug-Id:548033968 PiperOrigin-RevId: 967395453 Change-Id: I3a35abecf73df40b612bfa7c3d99430afa5273db
This project is Google's version of BMCWeb.
See Readme Google for Google added features. The following is the original README of OpenBMC/BMCWeb.
==============================================================================
This component attempts to be a “do everything” embedded webserver for OpenBMC.
The webserver implements a few distinct interfaces:
bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.
Bmcweb supports multiple authentication protocols:
Each of these types of authentication is able to be enabled or disabled both via runtime policy changes (through the relevant Redfish APIs) or via configure time options. All authentication mechanisms supporting username/password are routed to libpam, to allow for customization in authentication implementations.
All authorization in bmcweb is determined at routing time, and per route, and conform to the Redfish PrivilegeRegistry.
*Note: Non-Redfish functions are mapped to the closest equivalent Redfish privilege level.
bmcweb is configured per the meson build files. Available options are documented in meson_options.txt
meson builddir ninja -C builddir
If any of the dependencies are not found on the host system during configuration, meson will automatically download them via its wrap dependencies mentioned in bmcweb/subprojects.
bmcweb relies on some on-system data for storage of persistent data that is internal to the process. Details on the exact data stored and when it is read/written can seen from the persistent_data namespace.
When SSL support is enabled and a usable certificate is not found, bmcweb will generate a self-signed a certificate before launching the server. Please see the bmcweb source code for details on the parameters this certificate is built with.
bmcweb is capable of aggregating resources from satellite BMCs. Refer to AGGREGATION.md for more information on how to enable and use this feature.