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

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

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

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

thanks! applied in r1569