-
Notifications
You must be signed in to change notification settings - Fork 308
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
DAOS-17131 dfs: Possible missing string termination after strncpy function call #15920
base: master
Are you sure you want to change the base?
Conversation
Ticket title is 'Possible missing string termination after strncpy function call' |
da1f492
to
6624f78
Compare
There are several issues in strncpy usage that may cause memory corruption. Target string may not be ended by `\0` character. Issues detected during sanitizer integration Ref: #15105 Co-authored-by: Cedric Koch-Hofer <[email protected]> Co-autohred-by: Tomasz Gromadzki <[email protected]> Signed-off-by: Tomasz Gromadzki <[email protected]>
6624f78
to
d7915ac
Compare
src/client/dfs/cont.c
Outdated
@@ -83,7 +84,8 @@ dfs_cont_create(daos_handle_t poh, uuid_t *cuuid, dfs_attr_t *attr, daos_handle_ | |||
dattr.da_chunk_size = DFS_DEFAULT_CHUNK_SIZE; | |||
|
|||
if (attr->da_hints[0] != 0) { | |||
strncpy(dattr.da_hints, attr->da_hints, DAOS_CONT_HINT_MAX_LEN); | |||
/* DAOS-17042 Replace strncpy with strncat or strlcpy */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please remove all these comments from the code. they are not helpful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
patch looks good to me, but request to remove all the comments and the ticket number. there is no information gained from those comments overall in the code base.
ticket number should be used to note a known or TBD issue, but not fixes; otherwise code become unreadable if everyone does that.
Also please make sure to run with |
Possible missing string termination after strncpy function call. There are several places where using strncpy can cause memory corruption - the target string may not be terminated with `\0` character. Issue has been detected during sanitizer integration: #15105 Features: dfs Signed-off-by: Tomasz Gromadzki <[email protected]>
Done |
A new ticket has been created DAOS-17131. It is only related to issues detected by the sanitizer in #15105. There is another issue DAOS-17042 that addresses the general problem of possible misuse of strncpy(). |
Test stage NLT on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15920/4/testReport/ |
Parallel-build: true Skip-build-el8-rpm: true Skip-build-el9-rpm: true Skip-build-leap15-rpm: true Skip-build-ubuntu20-rpm: true Skip-build-el8-gcc-dev: true Skip-build-leap15-icc: true Skip-test: true Skip-unit-test: true Skip-unit-test-memcheck: true Skip-bullseye: true Signed-off-by: Tomasz Gromadzki <[email protected]>
Transient issue in CI fixed in the next build without any source code modification. |
what is the transient error? is it a known issue? more info is needed when saying the error is transient. it should be a known issue with a ticket. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is nothing wrong with the original implementation, IMO. We should address the consistency issue though
@@ -83,7 +84,7 @@ dfs_cont_create(daos_handle_t poh, uuid_t *cuuid, dfs_attr_t *attr, daos_handle_ | |||
dattr.da_chunk_size = DFS_DEFAULT_CHUNK_SIZE; | |||
|
|||
if (attr->da_hints[0] != 0) { | |||
strncpy(dattr.da_hints, attr->da_hints, DAOS_CONT_HINT_MAX_LEN); | |||
strncpy(dattr.da_hints, attr->da_hints, DAOS_CONT_HINT_MAX_LEN - 1); | |||
dattr.da_hints[DAOS_CONT_HINT_MAX_LEN - 1] = '\0'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation is actually perfectly fine. Are you see any issues with the original code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please take a look at #15105
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think the existing code has a bug. If attr->da_hints
is exactly DAOS_CONT_HINT_MAX_LEN
long, then strncpy copies the entire buffer as expected. But then dattr.da_hints[DAOS_CONT_HINT_MAX_LEN - 1] = '\0';
overwrites the last character.
E.g.
strncpy(dattr.da_hints, "1234", 4);
dattr.da_hints[4 - 1] = '\0';
Yields dattr.da_hints = "123\0"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, finally the string will be somehow OK, but it will be not the same string. The problem of strncpy misusage has been discussed in #15105
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then again I guess it doesn't matter because attr->da_hints
could be longer than DAOS_CONT_HINT_MAX_LEN
and not copied entirely anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading up on this more, it's not actually a misuse of strncpy, but just simply that -Wstringop-truncation
warns that you might lose data from the source string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, doing some local testing, the compiler complains either way. So this change doesn't solve anything
With
char my_string[4];
strncpy(my_string, "1234", 4);
my_string[4-1] = '\0';
It complains with
warning: ‘strncpy’ output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
strncpy(my_string, "1234", 4);
And with
char my_string[4];
strncpy(my_string, "1234", 4-1);
my_string[4-1] = '\0';
It complains with
warning: ‘strncpy’ output truncated copying 3 bytes from a string of length 4 [-Wstringop-truncation]
strncpy(my_string, "1234", 4-1);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. thanks for the explanation
@@ -510,7 +511,8 @@ dfs_dup(dfs_t *dfs, dfs_obj_t *obj, int flags, dfs_obj_t **_new_obj) | |||
D_GOTO(err, rc = EINVAL); | |||
} | |||
|
|||
strncpy(new_obj->name, obj->name, DFS_MAX_NAME + 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again this is fine too if the obj->name
is already valid.
I think a serious issue is about the consistency of using DFS_MAX_NAME
. Sometimes the name is defined as name[DFS_MAX_NAME + 1]
but sometimes it's name[DFS_MAX_NAME]
. I would prefer to use the latter and then redefining maximum object name as DFS_MAX_NAME
including the ending zero.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, this is the result of #15105 + see my comment above: #15920 (comment)
Issue has been created: https://daosio.atlassian.net/browse/DAOS-17149 |
Features: dfs Signed-off-by: Tomasz Gromadzki <[email protected]>
Test stage Functional Hardware Large completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15920/6/execution/node/1420/log |
There are several issues in strncpy usage that may cause memory corruption. Target string may not be ended by
\0
character.Issues detected during sanitizer integration
Ref: #15105
Co-authored-by: Cedric Koch-Hofer [email protected]
Co-autohred-by: Tomasz Gromadzki [email protected]
Signed-off-by: Tomasz Gromadzki [email protected]
Before requesting gatekeeper:
Features:
(orTest-tag*
) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.Gatekeeper: