Message ID | 20210222151231.22572-1-romain.perier@gmail.com |
---|---|
Headers | show |
Series | Manual replacement of all strlcpy in favor of strscpy | expand |
On 2/22/21 8:12 AM, Romain Perier wrote: > strlcpy() copy a C-String into a sized buffer, the result is always a > valid NULL-terminated that fits in the buffer, howerver it has severals > issues. It reads the source buffer first, which is dangerous if it is non > NULL-terminated or if the corresponding buffer is unbounded. Its safe > replacement is strscpy(), as suggested in the deprecated interface [1]. > > We plan to make this contribution in two steps: > - Firsly all cases of strlcpy's return value are manually replaced by the > corresponding calls of strscpy() with the new handling of the return > value (as the return code is different in case of error). > - Then all other cases are automatically replaced by using coccinelle. > Cool. A quick check shows me 1031 strscpy() calls with no return checks. All or some of these probably need to be reviewed and add return checks. Is this something that is in the plan to address as part of this work? thanks, -- Shuah
Hello! On 22.02.2021 18:12, Romain Perier wrote: > The strlcpy() reads the entire source buffer first, it is dangerous if > the source buffer lenght is unbounded or possibility non NULL-terminated. Length. Possibly? > It can lead to linear read overflows, crashes, etc... > > As recommended in the deprecated interfaces [1], it should be replaced > by strscpy. > > This commit replaces all calls to strlcpy that handle the return values > by the corresponding strscpy calls with new handling of the return > values (as it is quite different between the two functions). > > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy > > Signed-off-by: Romain Perier <romain.perier@gmail.com> [...] MBR, Sergei