Occasionally fcoemon fails to reply to fcoeadm when it's sent a request. When this happens fcoeadm eventually times out. It is the result of using memcpy and not strncpy when copying the sun_path received from the request.
Using memcpy is causing intermittent problems when copying the sun_path from socket information. sun_path is a string and therefore strncpy should be used. memcpy is not going to copy the terminating character becuase we're using strlen to determine the size. The problem is masked becuase much of the time the destination buffer must be NULL'd out before the copy, but if the buffer is not NULL'd out then we end up copying into a buffer without termination and when we try to reply to fcoeadm the sendto interface complains that there is no file that the sun_path is pointing to (becuase there is garbage in the string). This patch also adds 1 to the value returned by strlen. strlen doesn't account for the terminating character and strncpy won't add a '\0' if the source is the same size as the length. This means that room for the '\0' needs to be added. Signed-off-by: Robert Love <[email protected]> --- fcoemon.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fcoemon.c b/fcoemon.c index 46ba0f1..c485754 100644 --- a/fcoemon.c +++ b/fcoemon.c @@ -2159,7 +2159,7 @@ int fcm_save_reply(struct sock_info **r, struct sockaddr_un *f, socklen_t flen, } (*r)->sock = s; (*r)->from.sun_family = f->sun_family; - memcpy((*r)->from.sun_path, f->sun_path, strlen(f->sun_path)); + strncpy((*r)->from.sun_path, f->sun_path, strlen(f->sun_path) + 1); (*r)->fromlen = flen; return fcm_success; } _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
