3 ms·

Yet, it happens: https://nvd.nist.gov/vuln/detail/CVE-2017-14064 https://nvd.nist.gov/vuln/detail/CVE-2017-14064 https://nvd.nist.gov/vuln/detail/CVE-2015-318

• tedunangst 8y ago
  This is true. Although they did say "copy a string", not use strdup to copy a thing that is not a string. :)
  • sunfish 8y ago
    Yes, that's one of the three CVE's I posted ;). You got me thinking about ways one could get strdup wrong: - input is not a string -> possible UB - input is a string, but the character encoding wasn't what you thought -> possible UB - input is a string, but it was the pointer-plus-length kind -> possible UB - input is modified by another thread -> possible UB - strdup called from within a signal handler -> possible UB - failure to handle error return values -> possible UB - failure to free the memory when it's no longer needed -> memory leak - freed the memory more than once -> possible UB - used the memory after freeing it -> possible UB I've personally seen several of these in real-world code.
    • sunfish 8y ago
      How did I forget: - forget to #include string.h, so strdup is implicitly declared, so its return type is int, which implicitly converts to char*, so everything still compiles -> possible UB