Messages in this thread | | | From | Kees Cook <> | Date | Mon, 14 Jan 2019 17:02:51 -0800 | Subject | Re: [PATCH 1/8] lkdtm: change snprintf to scnprintf for possible overflow |
| |
On Sat, Jan 12, 2019 at 7:28 AM Willy Tarreau <w@1wt.eu> wrote: > > From: Silvio Cesare <silvio.cesare@gmail.com> > > Change snprintf to scnprintf. There are generally two cases where using > snprintf causes problems.
(I didn't find a 0/8 cover letter, so I'm replying here...)
Many of these fixes are just robustness updates (e.g. the lkdtm case below is not current a problem: the size of the static array getting displayed is less than PAGE_SIZE). It might be worth noting which are actually problems (and include the appropriate Cc: and Fixes: lines).
> > 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) > In this case, if snprintf would have written more characters than what the > buffer size (SIZE) is, then size will end up larger than SIZE. In later > uses of snprintf, SIZE - size will result in a negative number, leading > to problems. Note that size might already be too large by using > size = snprintf before the code reaches a case of size += snprintf. > > 2) If size is ultimately used as a length parameter for a copy back to user > space, then it will potentially allow for a buffer overflow and information > disclosure when size is greater than SIZE. When the size is used to index > the buffer directly, we can have memory corruption. This also means when > size = snprintf... is used, it may also cause problems since size may become > large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel > configuration. > > The solution to these issues is to use scnprintf which returns the number of > characters actually written to the buffer, so the size variable will never > exceed SIZE. > > Signed-off-by: Silvio Cesare <silvio.cesare@gmail.com> > Cc: Dan Carpenter <dan.carpenter@oracle.com> > Cc: Kees Cook <keescook@chromium.org> > Cc: Will Deacon <will.deacon@arm.com> > Cc: Greg KH <greg@kroah.com> > Signed-off-by: Willy Tarreau <w@1wt.eu>
Are these changes going into someone's single tree, or are they intended for individual maintainers to pick up?
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
> > --- > drivers/misc/lkdtm/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c > index 2837dc77478e..610aa3bfe630 100644 > --- a/drivers/misc/lkdtm/core.c > +++ b/drivers/misc/lkdtm/core.c > @@ -347,9 +347,9 @@ static ssize_t lkdtm_debugfs_read(struct file *f, char __user *user_buf, > if (buf == NULL) > return -ENOMEM; > > - n = snprintf(buf, PAGE_SIZE, "Available crash types:\n"); > + n = scnprintf(buf, PAGE_SIZE, "Available crash types:\n"); > for (i = 0; i < ARRAY_SIZE(crashtypes); i++) { > - n += snprintf(buf + n, PAGE_SIZE - n, "%s\n", > + n += scnprintf(buf + n, PAGE_SIZE - n, "%s\n", > crashtypes[i].name); > } > buf[n] = '\0'; > -- > 2.19.2 >
-- Kees Cook
| |