summaryrefslogtreecommitdiffstats
path: root/source3/smbd/reply.c
diff options
context:
space:
mode:
authorVolker Lendecke <vl@samba.org>2009-05-24 18:57:13 +0200
committerVolker Lendecke <vl@samba.org>2009-05-24 18:57:13 +0200
commit68c5c6df0eeae16c56d0abc1b5ec275d18410224 (patch)
treebe11c7b7f787243656022f4fa96fc834bc7a6634 /source3/smbd/reply.c
parente744b0af683b459d5eeaf65f4f8d95b0e10c8ec6 (diff)
downloadsamba-68c5c6df0eeae16c56d0abc1b5ec275d18410224.tar.gz
samba-68c5c6df0eeae16c56d0abc1b5ec275d18410224.tar.xz
samba-68c5c6df0eeae16c56d0abc1b5ec275d18410224.zip
Fix a race condition in winbind leading to a panic
In winbind, we do multiple events in one select round. This needs fixing, but as long as we're still using it, for efficiency reasons we need to do that. What can happen is the following: We have outgoing data pending for a client, thus state->fd_event.flags == EVENT_FD_WRITE Now a new client comes in, we go through the list of clients to find an idle one. The detection for idle clients in remove_idle_client does not take the pending data into account. We close the socket that has pending outgoing data, the accept(2) one syscall later gives us the same socket. In new_connection(), we do a setup_async_read, setting up a read fde. The select from before however had found the socket (that we had already closed!!) to be writable. In rw_callback we only want to see a readable flag, and we panic in the SMB_ASSERT(flags == EVENT_FD_READ). Found using bin/smbtorture //127.0.0.1/tmp -U% -N 500 -o 2 local-wbclient Volker
Diffstat (limited to 'source3/smbd/reply.c')
0 files changed, 0 insertions, 0 deletions