Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jgrills opened this issue May 22, 2024 · 4 comments

Comments

@jgrills
Copy link

jgrills commented May 22, 2024

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
Copy link
Author

jgrills commented May 22, 2024

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
Copy link
Member

yoe commented Aug 6, 2024

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

nbd/cliserv.c

Lines 75 to 79 in 99cb654

void err(const char *s) {
err_nonfatal(s);
fprintf(stderr, "Exiting.\n");
exit(EXIT_FAILURE);
}

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

What did you do?

@yoe yoe closed this as completed Aug 6, 2024
@jgrills
Copy link
Author

jgrills commented Aug 6, 2024

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
Copy link
Member

yoe commented Aug 7, 2024

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.

@yoe yoe reopened this Aug 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants