SIGSEGV in l2cap_run when remote closed second of two connections

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run l2cap-server.
2. Open both connections, i.e. from a remote device open PSM 17, and open PSM 
19.
3. On the remote device close the second(!) connection.
4. See crash in daemon.

What is the expected output? What do you see instead?

No crash, instead we see:
Program received signal SIGSEGV, Segmentation fault.
0x0040ac1e in l2cap_run () at l2cap.c:348
348     next = it->next;
(gdb) bt
#0  0x0040ac1e in l2cap_run () at l2cap.c:348
#1  0x0040b5b2 in l2cap_handle_disconnect_request (channel=0xca3050,
    identifier=5) at l2cap.c:610
#2  0x0040ba13 in l2cap_signaling_handler_channel (channel=0xca3050,
    command=0x417842 "\006\005\004") at l2cap.c:744
#3  0x0040bd98 in l2cap_signaling_handler_dispatch (handle=40,
    command=0x417842 "\006\005\004") at l2cap.c:895
#4  0x0040be18 in l2cap_acl_handler (packet=0x41783a "( \f", size=16)
    at l2cap.c:918
#5  0x0040bee2 in l2cap_packet_handler (packet_type=2 '\002',
    packet=0x41783a "( \f", size=16) at l2cap.c:942
#6  0x00405ce3 in acl_handler (packet=0x41783a "( \f", size=16) at hci.c:319
#7  0x00406639 in packet_handler (packet_type=2 '\002',
    packet=0x41783a "( \f", size=16) at hci.c:691
#8  0x00409726 in tusb_process_ds (ds=0x0)
    at 3hci_transport_libusb-win32.c:235
#9  0x004097c8 in tusb_process_ts (timer=0x418068)
    at 3hci_transport_libusb-win32.c:283
#10 0x00401b5f in posix_execute () at run_loop_posix.c:182
#11 0x004017e3 in run_loop_execute () at run_loop.c:112
#12 0x0040563f in main (argc=1, argv=0xc99fc0) at daemon.c:733

What version of the product are you using? On what operating system?

svnversion: 1557M,  Windows+Cygwin

Please provide any additional information below.

In l2cap_run the run in this case is doing "case 
L2CAP_STATE_WILL_SEND_DISCONNECT_RESPONSE:", and thus free-ing the current 
item.  So when we access its next pointer we get corrupt memory, see below.  
Patch attached.

• Zero conns:
before 'for': l2cap_channels: 0x0
(L->NULL)

• One conn
before 'for': l2cap_channels: 0xcd3018
  cur: 0xcd3018
  after body: next: 0x0, it->next: 0x0
(L->0xcd3018->NULL)

• Two conns
before 'for': l2cap_channels: 0xcd3050
  cur: 0xcd3050
  after body: next: 0xcd3018, it->next: 0xcd3018
  cur: 0xcd3018
  after body: next: 0x0, it->next: 0x0
(L->0xcd3050->0xcd3018->NULL)

• Going back to one conn
before 'for': l2cap_channels: 0xcd3050
  cur: 0xcd3050
  free
! after body: next: 0xcd3018, it->next: 0x611da1f8 ** OOPS **
  cur: 0x611da1f8
  after body: next: 0x6115c3b0, it->next: 0x6115c3b0
  cur: 0x6115c3b0
  after body: next: 0x8be58955, it->next: 0x8be58955

Original issue reported on code.google.com by alanj...@yahoo.com on 8 Nov 2011 at 2:56

Attachments:

• l2cap_run__next.diff

[GoogleCodeExporter]

Looks like rfcomm.c is ready to handle such a situation. :-)

Original comment by alanj...@yahoo.com on 8 Nov 2011 at 3:13

[GoogleCodeExporter]

thanks for reporting and even providing a patch. what do you mean by "rfcomm.c 
is ready to handle.."?

Original comment by matthias.ringwald@gmail.com on 8 Nov 2011 at 9:30

[GoogleCodeExporter]

Just that rfcomm.c does already handles this situation -- by storing 'next' at 
the top of the loop.

Original comment by alanj...@yahoo.com on 8 Nov 2011 at 9:45

[GoogleCodeExporter]

thanks! applied in r1569

Original comment by matthias.ringwald@gmail.com on 9 Nov 2011 at 4:38

• Changed state: Fixed