[BUG] Null Pointer Dereference in chip-im-responder

[BoB13-Matter]

Reproduction steps

1. Open Terminal 1 and start the chip-im-responder:

   $ ./chip-im-responder

2. Open Terminal 2 and start the chip-im-initiator with its own IPv6 address ::1:

   $ ./chip-im-initiator ::1

3. Observe the output in chip-im-responder and check sanitizer logs for a null pointer dereference.
   chip-im-responder log.txt

Description

• While running the chip-im-responder and sending a command using chip-im-initiator, the function InteractionModelEngine::CheckCommandExistence() calls GetDataModelProvider(), which directly returns a nullptr when mDataModelProvider is uninitialized or unset. This leads to a null pointer dereference at InteractionModelEngine.cpp:1789.

• Previously, a null-check for mDataModelProvider existed in InteractionModelEngine::GetDataModelProvider() (refer to InteractionModelEngine.cpp:1858). However, this check appears to have been removed in a recent change, potentially causing this regression.

  DataModel::Provider * InteractionModelEngine::GetDataModelProvider() const
  {
  [-] if (mDataModelProvider == nullptr)
  [-] {
          // These should be called within the CHIP processing loop.
          assertChipStackLockedByCurrentThread();
  [-]     SetDataModelProvider(CodegenDataModelProviderInstance());
  [-] }
      return mDataModelProvider;
  }

Bug prevalence

always

GitHub hash of the SDK that was being used

29c6fd8

Platform

core

Platform Version(s)

all versions

Anything else?

No response

[andy31415]

#35749 disabled this test in CI because the im-responder assumes it can just override a subset of methods without having a consistent data model (so making it work is non-trivial)