Bug 14433 - There's a race between smb2srv_client_lookup_global and smb2srv_client_connection_pass
Summary: There's a race between smb2srv_client_lookup_global and smb2srv_client_connec...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.12.5
Hardware: All All
: P5 critical (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 14534
  Show dependency treegraph
 
Reported: 2020-07-06 13:34 UTC by Stefan Metzmacher
Modified: 2020-10-14 13:02 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Metzmacher 2020-07-06 13:34:28 UTC
The samba3.blackbox.durable_v2_delay test triggers
a race where the first connection with a specific client_guid
already entered exit_server_common(), but didn't left it
before the 2nd connection with the same client_guid is accepted.

The smbd child for the 2nd connection found the smbXsrv_client record
of the first connection and used smb2srv_client_connection_pass()
in order to send the new connection over, but it doesn't wait
for any kind of ack, that the connection was actually taken over.

We need an MSG_SMBXSRV_CONNECTION_ACCEPTED as response to
MSG_SMBXSRV_CONNECTION_PASS.

After calling smb2srv_client_connection_pass(), the sending process
needs to watch the smbXsrv_client.tdb record and wait for a
MSG_SMBXSRV_CONNECTION_ACCEPTED message.

If we get MSG_SMBXSRV_CONNECTION_ACCEPTED we can exit the new process.

If the smbXsrv_client record got removed, the new process should go on
and take care of the new connection, as if it would have been the
first connection for that client guid.
Comment 1 Stefan Metzmacher 2020-07-24 16:06:30 UTC
Mark as regression in order to remember it for 4.13.0 if possible
Comment 2 Björn Jacke 2020-07-27 17:05:06 UTC
We moved from blocker to regession bug status because we do not want to have a nice-to-have bug list that blocks the next release. If this is a regression from the previous release it should have the regression status, otherwise it should not. This is the otherwise case, isn't it? ;-)