Bluetooth: Mesh: Null check buf before unref
The frnd->last buffer can potentially be NULL if friend_clear is called after the adv.c buf->busy check, but before the adv_start callback. The current design is based on the adv.c thread being cooperative, and therefore not yielding between the busy check and the adv_start callback, but as the bt_le_adv_start call has to acquire a semaphore, there's a possibility for friend_clear being called inbetween. Fixes #26177. Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
This commit is contained in:
parent
2cab72788e
commit
ca901c2149
1 changed files with 1 additions and 1 deletions
|
@ -1085,7 +1085,7 @@ static void buf_send_start(uint16_t duration, int err, void *user_data)
|
|||
frnd->pending_buf = 0U;
|
||||
|
||||
/* Friend Offer doesn't follow the re-sending semantics */
|
||||
if (!frnd->established) {
|
||||
if (!frnd->established && frnd->last) {
|
||||
net_buf_unref(frnd->last);
|
||||
frnd->last = NULL;
|
||||
}
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue