rpm: Reset RPM log callback upon RpmLogGuard destruction

This patch addresses undefined behavior that occurs when the RPM log
callback function is invoked after the RpmLogGuard object has been
destroyed. The issue arises because rpmlogCallbackData retains a
reference to the destroyed object.

The problem manifests during the execution of the builddep plugin command:

1. During Vars::detect_release, the RPM log callback is set via RpmLogGuard.
2. After the release version is detected, the RpmLogGuard object is destroyed.
3. A subsequent call to rpmSpecParse() by the builddep command may
   trigger the previously set log callback.
4. This results in undefined behavior because the callback data still
   points to the destroyed RpmLogGuard.

By resetting the RPM log callback upon RpmLogGuard destruction, this
patch ensures safe and predictable behavior.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2326535
Resolves: #1864

libdnf5/rpm/rpm_log_guard.cpp

@@ -65,6 +65,16 @@ static int rpmlog_callback(rpmlogRec rec, rpmlogCallbackData data) {
     return 0;
 }
 
+RpmLogGuardBase::~RpmLogGuardBase() {
+    // Reset the RPM log callback to nullptr to prevent undefined behavior if the
+    // callback data retains a reference to the RpmLogGuard object after it has
+    // been destroyed.
+    // The class doesn't reset the original callback upon destruction, because
+    // although `rpmlogSetCallback()` returns the old callback, there's no way
+    // to also retrieve the `rpmlogCallbackData` associated with it, so the
+    // data can't be reset.
+    rpmlogSetCallback(nullptr, nullptr);
+}
 
 RpmLogGuard::RpmLogGuard(const BaseWeakPtr & base) : RpmLogGuardBase(), base(base) {
     rpmlogSetCallback(&rpmlog_callback, this);

libdnf5/rpm/rpm_log_guard.hpp

@@ -31,7 +31,7 @@ namespace libdnf5::rpm {
 class RpmLogGuardBase {
 public:
     RpmLogGuardBase() : rpm_log_mutex_guard(rpm_log_mutex) {}
-    ~RpmLogGuardBase() {}
+    virtual ~RpmLogGuardBase();
 
 private:
     static std::mutex rpm_log_mutex;