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

src/libudev/conf-files.c: fix bug of using basename #198

Merged
merged 1 commit into from
Oct 6, 2021

Conversation

xfan1024
Copy link
Contributor

@xfan1024 xfan1024 commented Aug 14, 2021

BASENAME(3) Linux Programmer's Manual say:

These functions may return pointers to statically allocated memory
which may be overwritten by subsequent calls.

Using basename return value as key of hashmap is not safe, it may
cause that hashmap_put always return -EEXIST if hash collision happen.

Using basename return value as strcmp first and second parameters may
always return 0.

@xfan1024 xfan1024 force-pushed the master branch 3 times, most recently from bb232d7 to 7a4377b Compare August 14, 2021 21:18
@lu-zero lu-zero requested a review from akhuettel August 17, 2021 14:24
@lu-zero
Copy link
Contributor

lu-zero commented Aug 22, 2021

basename_r is non-standard so doesn't look like we can have a simpler workaround.

@xfan1024
Copy link
Contributor Author

basename_r is non-standard so doesn't look like we can have a simpler workaround.

Is it acceptable using custom basename_internal?

@bbonev
Copy link
Member

bbonev commented Sep 20, 2021

src/shared/conf-files.c:145: fh = hashmap_new(&string_hash_ops);

string_hash_func calculates the hash based on the string value, not the pointer, so that part is safe

But this one is not: return strcmp(basename(s1), basename(s2)); as long as the second call may return the same memory as the first one and overwrite the contents... Also it is mentioned that basename may modify its argument and then a real mess would happen.

Instead of looping over all path components, what about using strrchr?

@ArsenArsen
Copy link
Member

Holding an implementation of a function is quite fine, though, as noted, strrchr might save on some code in there.

@bbonev
Copy link
Member

bbonev commented Sep 21, 2021

While at it, maybe it is a good idea to also include this:

src/shared/util.c:1728: fn = basename((char*)p);

It discards the const modifier and violates POSIX...

@bbonev
Copy link
Member

bbonev commented Oct 4, 2021

@xfan1024 What about that:

const char *eudev_basename(const char *filename) {
    char *p=strrchr(filename,'/');
  
    if (p)
        return p+1;
    return filename;
}

Because this is used in more than one place, it would best to put it in src/shared/util.c and the prototype in util.h

@bbonev bbonev removed the request for review from akhuettel October 4, 2021 23:45
@xfan1024
Copy link
Contributor Author

xfan1024 commented Oct 5, 2021

@xfan1024 What about that:

const char *eudev_basename(const char *filename) {
    char *p=strrchr(filename,'/');
  
    if (p)
        return p+1;
    return filename;
}

Because this is used in more than one place, it would best to put it in src/shared/util.c and the prototype in util.h

Agree it.

@xfan1024
Copy link
Contributor Author

xfan1024 commented Oct 5, 2021

src/shared/conf-files.c:145: fh = hashmap_new(&string_hash_ops);

string_hash_func calculates the hash based on the string value, not the pointer, so that part is safe

hashmap hold string's pointer not string's value. hashmap_put have 2 steps to check the key is exists, first calculate string's hash code, second strcmp all string in hashmap which have the same hash code, that equivalent to strcmp(basename(s1), basename(s2)), so I think that also unsafe.

@xfan1024 xfan1024 force-pushed the master branch 2 times, most recently from 40912bc to baa7e20 Compare October 5, 2021 16:05
@bbonev
Copy link
Member

bbonev commented Oct 5, 2021

There is one more invocation - src/shared/util.c:1728
Please fix that too and it's good to merge

BASENAME(3) Linux Programmer's Manual say:
> These functions may return pointers to statically allocated memory
> which may be overwritten by subsequent calls.

Using basename return value as key of hashmap is not safe, it may
cause that hashmap_put always return -EEXIST if hash collision happen.

Using basename return value as strcmp first and second parameters may
always return 0.

Signed-off-by: xiaofan <xiaofan@iscas.ac.cn>
@xfan1024
Copy link
Contributor Author

xfan1024 commented Oct 6, 2021

There is one more invocation - src/shared/util.c:1728 Please fix that too and it's good to merge

Done

Copy link
Member

@bbonev bbonev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution to eudev!

@bbonev bbonev merged commit 3b1286f into eudev-project:master Oct 6, 2021
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

Successfully merging this pull request may close these issues.

4 participants