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
2 files changed
tree: 47fa9063fbdfca14f2a1fba72d17105b7f07f64f
  1. .github/
  2. config/
  3. devpath_plugin/
  4. g3/
  5. http/
  6. include/
  7. install/
  8. plugins/
  9. redfish-core/
  10. redfish_authorization/
  11. scripts/
  12. src/
  13. static/
  14. subprojects/
  15. test/
  16. tlbmc/
  17. .clang-format
  18. .clang-tidy
  19. .clang-tidy-ignore
  20. .dockerignore
  21. .gitignore
  22. .markdownlint.yaml
  23. .openbmc-enforce-gitlint
  24. .openbmc-no-clang
  25. .openbmc-no-sanitize
  26. .prettierignore
  27. .shellcheck
  28. AGGREGATION.md
  29. CLIENTS.md
  30. COMMON_ERRORS.md
  31. copy.bara.sky
  32. DBUS_USAGE.md
  33. DEVELOPING.md
  34. gcovr.cfg
  35. HEADERS.md
  36. LICENSE
  37. meson.build
  38. meson_options.txt
  39. OEM_SCHEMAS.md
  40. OWNERS
  41. PLUGINS.md
  42. README.md
  43. README_GOOGLE.md
  44. Redfish.md
  45. run-ci
  46. setup.cfg
  47. TESTING.md
  48. UNIT_TESTING.md
README.md

OpenBMC webserver

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.

Features

The webserver implements a few distinct interfaces:

  • DBus event websocket. Allows registering on changes to specific dbus paths, properties, and will send an event from the websocket if those filters match.
  • OpenBMC DBus REST api. Allows direct, low interference, high fidelity access to dbus and the objects it represents.
  • Serial: A serial websocket for interacting with the host serial console through websockets.
  • Redfish: A protocol compliant, DBus to Redfish translator.
  • KVM: A websocket based implementation of the RFB (VNC) frame buffer protocol intended to mate to webui-vue to provide a complete KVM implementation.

Protocols

bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.

AuthX

Authentication

Bmcweb supports multiple authentication protocols:

  • Basic authentication per RFC7617
  • Cookie based authentication for authenticating against webui-vue
  • Mutual TLS authentication based on OpenSSL
  • Session authentication through webui-vue
  • XToken based authentication conformant to Redfish DSP0266

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.

Authorization

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.

Configuration

bmcweb is configured per the meson build files. Available options are documented in meson_options.txt

Compile bmcweb with default options

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.

Use of persistent data

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.

TLS certificate generation

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.

Redfish Aggregation

bmcweb is capable of aggregating resources from satellite BMCs. Refer to AGGREGATION.md for more information on how to enable and use this feature.