If the client connects to the nbd socket, and then disconnects without sending any data, nbd floods the logs

[jgrills]

Since the socket_read() in the server negotiation in negotiate(..) doesn't return any sort of error, the server acts on uninitialized data and can spin around the loop, each read/write spamming the error in socket_closed_negotiate()

[jgrills]

In particular, because magic was used to send the magic number, when it fails to read at https://github.com/NetworkBlockDevice/nbd/blob/master/nbd-server.c#L2678 it will have the correct magic number, and things will proceed.

opt is not initialized and just about anything could happen after that.

As a fix, I might suggest changing socket_read() to memset(buf, 0, len); if the read returns less than 0, here: https://github.com/NetworkBlockDevice/nbd/blob/master/nbd-server.c#L365

[yoe]

The "err" function ends with exit(EXIT_FAILURE), unconditionally:

https://github.com/NetworkBlockDevice/nbd/blob/99cb65476224a55a98f74581cc87a2ad711e1f7e/cliserv.c#L75-L79

There is no world in which an unmodified version of nbd could do that and loop.

What did you do?

[jgrills]

I simply opened that socket and closed it, I didn't send any data at all, I didn't use nbd at all. I have a very specific scenario where I need to check connectivity to an NBD server running on a device that may be in sleep.

A port scan of a system might do this too. You really should handle this case cleanly.

[yoe]

My point is, we do handle this case cleanly. I tried to reproduce it before closing this issue, but I could not.

I opened the port with nc while running nbd-server in a debugger, waited for the port to be open, and then immediately closed it.

The server correctly handled the case by logging that message and then exiting.

So I do not know what is different in your setup. But the bug does not seem to exist in my environment.

Perhaps I was a bit fast with closing it, so I'm reopening now. But you must be doing something different from me that causes it to appear.