Fix potential null dereference in rd_kafka_assign_ranges() when member assignment lookup fails

[lhywk]

Describe

Hi,

In the function rd_kafka_assign_ranges(), a pointer member_assignment is obtained via a call to:

rd_kafka_find_member_assigned_partitions_pair_by_member_id()

This function may return NULL if the specified member_id has no matching entry in the list member_to_assigned_partitions.

Previously, the return value was used without checking for NULL:

rd_list_cnt(member_assignment->assigned_partitions);

This is unsafe because rd_list_cnt() directly accesses the internal field rl->rl_cnt without validating the pointer:

static RD_INLINE RD_UNUSED int rd_list_cnt(const rd_list_t *rl) {
    return rl->rl_cnt;
}

If member_assignment is NULL, this leads to an immediate null pointer dereference and undefined behavior.

Expected Behavior

If no assignment is found for a given member, the member should be skipped safely without any dereferencing of null pointers.

Actual Behavior

When rd_kafka_find_member_assigned_partitions_pair_by_member_id() returns NULL, the code previously proceeded to access member_assignment->assigned_partitions, resulting in undefined behavior due to null pointer dereference.

How to Reproduce

This issue can occur when:

1. The member_to_assigned_partitions list does not contain an entry for a specific member_id.
2. rd_kafka_find_member_assigned_partitions_pair_by_member_id() returns NULL.
3. member_assignment->assigned_partitions is accessed unconditionally.
4. This leads to a null pointer dereference inside rd_list_cnt().

By adding a null check and skipping such members, this patch avoids the unsafe behavior.

Thanks for reviewing.

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
✅ lhywk
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}