On Sat, Aug 16, 2014 at 4:14 PM, Rickard Strandqvist <rickard_strandqvist@xxxxxxxxxxxxxxxxxx> wrote: > 2014-08-12 16:58 GMT+02:00 Kees Cook <keescook@xxxxxxxxxxxx>: >> On Sat, Aug 9, 2014 at 4:46 PM, Rickard Strandqvist >> <rickard_strandqvist@xxxxxxxxxxxxxxxxxx> wrote: >>> Added a guaranteed null-terminate after call to strncpy. >>> >>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@xxxxxxxxxxxxxxxxxx> >>> --- >>> drivers/staging/lustre/lustre/libcfs/workitem.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/staging/lustre/lustre/libcfs/workitem.c b/drivers/staging/lustre/lustre/libcfs/workitem.c >>> index 0a03bf7..60326f2 100644 >>> --- a/drivers/staging/lustre/lustre/libcfs/workitem.c >>> +++ b/drivers/staging/lustre/lustre/libcfs/workitem.c >>> @@ -365,6 +365,7 @@ cfs_wi_sched_create(char *name, struct cfs_cpt_table *cptab, >>> return -ENOMEM; >>> >>> strncpy(sched->ws_name, name, CFS_WS_NAME_LEN); >>> + sched->ws_name[CFS_WS_NAME_LEN - 1] = '\0'; >>> sched->ws_cptab = cptab; >>> sched->ws_cpt = cpt; >> >> This seems like a place for strlcpy instead? >> >> -Kees >> >> -- >> Kees Cook >> Chrome OS Security > > Hi Kees > > Sure, strlcpy is preferable in many ways if we only can guarantee that > it is safe. > I have seldom received so much criticism when I start switching to > strlcpy, although much of it was justified :) > Even Linus was getting into the debate. See more: > > https://plus.google.com/111049168280159033135/posts/1amLbuhWbh5 > > > I do this only when I'm sure it will not cause any other problems. > But if you or anyone else can guarantee that in this case, so I'd make > a new patch with strlcpy. Ah right, yeah, that limitation is weird. In that case, for your original patch: Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -Kees -- Kees Cook Chrome OS Security _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
