RFCOMM: Refuse connection if max RFCOMM ports are used

Issue:
When max RFCOMM ports are used, the stack returns the current listening
port as new port while accepting the incoming RFCOMM connection.
This leads to an assert.

Steps to reproduce
==================
1. Connect DUT with RFCOMM clients until all 30 RFCOMM ports used.
   (DUT using 17 ports for RFCOMM servers and 13 ports for clients)
3. Initiate SPP connection from remote to DUT

Bluetooth restarted due to assert in RFCOMM

Expected results: Incoming connection fails
Fix: Return null instead of current listening port when new port
     creation fails

Test: Simulated scenario by reducing max rfc ports and tested
Bug: 147075796
Change-Id: I46cd8e6707575e9cb92670136c9d6e4b9988eb53

diff --git a/bta/jv/bta_jv_act.cc b/bta/jv/bta_jv_act.cc
index 5cd8041..9965c71 100644 (file)
--- a/bta/jv/bta_jv_act.cc
+++ b/bta/jv/bta_jv_act.cc
@@ -1620,6 +1620,9 @@ static tBTA_JV_PCB* bta_jv_add_rfc_port(tBTA_JV_RFC_CB* p_cb,
         p_pcb->handle = BTA_JV_RFC_H_S_TO_HDL(p_cb->handle, si);
         VLOG(2) << __func__ << ": p_pcb->handle=" << loghex(p_pcb->handle)
                 << ", curr_sess=" << p_cb->curr_sess;
+      } else {
+        LOG(ERROR) << __func__ << ": RFCOMM_CreateConnection failed";
+        return NULL;
       }
     } else {
       LOG(ERROR) << __func__ << ": cannot create new rfc listen port";