From: Tinet-mucw <mucw@ti-net.com.cn>
Date: Fri, 14 Jun 2024 02:16:36 +0000 (-0700)
Subject: bridge_basic.c: Make sure that ast_bridge_channel is not destroyed while iterating... 
X-Git-Tag: 18.24.0-rc1~13
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c759489d3e14dc3821079e1cd2818b314b8fa88a;p=thirdparty%2Fasterisk.git

bridge_basic.c: Make sure that ast_bridge_channel is not destroyed while iterating over bridge->channels.
From the gdb information, we can see that while iterating over bridge->channels, the ast_bridge_channel reference count is 0, indicating it has already been destroyed.Additionally, when ast_bridge_channel is removed from bridge->channels, the bridge is first locked. Therefore, locking the bridge before iterating over bridge->channels can resolve the race condition.

Resolves: https://github.com/asterisk/asterisk/issues/768
(cherry picked from commit a1d0dac6c681e7cd2a15634907f729a9fd76259c)
---

diff --git a/main/bridge_basic.c b/main/bridge_basic.c
index 38a9e6c17f..da19b96b58 100644
--- a/main/bridge_basic.c
+++ b/main/bridge_basic.c
@@ -1856,7 +1856,9 @@ static void bridge_ringing(struct ast_bridge *bridge)
 		.subclass.integer = AST_CONTROL_RINGING,
 	};
 
+	ast_bridge_lock(bridge);
 	ast_bridge_queue_everyone_else(bridge, NULL, &ringing);
+	ast_bridge_unlock(bridge);
 }
 
 /*!
@@ -1869,7 +1871,9 @@ static void bridge_hold(struct ast_bridge *bridge)
 		.subclass.integer = AST_CONTROL_HOLD,
 	};
 
+	ast_bridge_lock(bridge);
 	ast_bridge_queue_everyone_else(bridge, NULL, &hold);
+	ast_bridge_unlock(bridge);
 }
 
 /*!
@@ -1882,7 +1886,9 @@ static void bridge_unhold(struct ast_bridge *bridge)
 		.subclass.integer = AST_CONTROL_UNHOLD,
 	};
 
+	ast_bridge_lock(bridge);
 	ast_bridge_queue_everyone_else(bridge, NULL, &unhold);
+	ast_bridge_unlock(bridge);
 }
 
 /*!