drivers/misc/lkdtm/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
From: "GONG, Ruiqi" <gongruiqi1@huawei.com>
Make use of the return value of strim() to achieve left-trim as well as
right-trim, which prevents the following unusual fail case:
# echo " EXCEPTION" > /sys/kernel/debug/provoke-crash/DIRECT
sh: write error: Invalid argument
Link: https://github.com/KSPP/linux/issues/337
Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com>
---
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 0772e4a4757e..812c96461ab2 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -242,7 +242,7 @@ static ssize_t lkdtm_debugfs_entry(struct file *f,
}
/* NULL-terminate and remove enter */
buf[count] = '\0';
- strim(buf);
+ buf = strim(buf);
crashtype = find_crashtype(buf);
free_page((unsigned long)buf);
@@ -318,7 +318,7 @@ static ssize_t direct_entry(struct file *f, const char __user *user_buf,
}
/* NULL-terminate and remove enter */
buf[count] = '\0';
- strim(buf);
+ buf = strim(buf);
crashtype = find_crashtype(buf);
free_page((unsigned long) buf);
--
2.25.1
On Thu, Aug 17, 2023 at 10:21:17PM +0800, GONG, Ruiqi wrote: > From: "GONG, Ruiqi" <gongruiqi1@huawei.com> > > Make use of the return value of strim() to achieve left-trim as well as > right-trim, which prevents the following unusual fail case: > > # echo " EXCEPTION" > /sys/kernel/debug/provoke-crash/DIRECT > sh: write error: Invalid argument And that is correct, don't use leading whitespace, the kernel is not there to parse it away :) thanks, greg k-h
On Thu, Aug 17, 2023 at 10:21:17PM +0800, GONG, Ruiqi wrote: > From: "GONG, Ruiqi" <gongruiqi1@huawei.com> > > Make use of the return value of strim() to achieve left-trim as well as > right-trim, which prevents the following unusual fail case: > > # echo " EXCEPTION" > /sys/kernel/debug/provoke-crash/DIRECT > sh: write error: Invalid argument > > Link: https://github.com/KSPP/linux/issues/337 > Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com> > --- > 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 0772e4a4757e..812c96461ab2 100644 > --- a/drivers/misc/lkdtm/core.c > +++ b/drivers/misc/lkdtm/core.c > @@ -242,7 +242,7 @@ static ssize_t lkdtm_debugfs_entry(struct file *f, > } > /* NULL-terminate and remove enter */ > buf[count] = '\0'; > - strim(buf); > + buf = strim(buf); > > crashtype = find_crashtype(buf); > free_page((unsigned long)buf); Will free_page() still work in this case, though? The address won't match the allocation any more... -Kees > @@ -318,7 +318,7 @@ static ssize_t direct_entry(struct file *f, const char __user *user_buf, > } > /* NULL-terminate and remove enter */ > buf[count] = '\0'; > - strim(buf); > + buf = strim(buf); > > crashtype = find_crashtype(buf); > free_page((unsigned long) buf); > -- > 2.25.1 > -- Kees Cook
On 2023/08/18 0:55, Kees Cook wrote: > On Thu, Aug 17, 2023 at 10:21:17PM +0800, GONG, Ruiqi wrote: >> From: "GONG, Ruiqi" <gongruiqi1@huawei.com> >> >> Make use of the return value of strim() to achieve left-trim as well as >> right-trim, which prevents the following unusual fail case: >> >> # echo " EXCEPTION" > /sys/kernel/debug/provoke-crash/DIRECT >> sh: write error: Invalid argument >> >> Link: https://github.com/KSPP/linux/issues/337 >> Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com> >> --- >> 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 0772e4a4757e..812c96461ab2 100644 >> --- a/drivers/misc/lkdtm/core.c >> +++ b/drivers/misc/lkdtm/core.c >> @@ -242,7 +242,7 @@ static ssize_t lkdtm_debugfs_entry(struct file *f, >> } >> /* NULL-terminate and remove enter */ >> buf[count] = '\0'; >> - strim(buf); >> + buf = strim(buf); >> >> crashtype = find_crashtype(buf); >> free_page((unsigned long)buf); > > Will free_page() still work in this case, though? The address won't > match the allocation any more... Yes I noticed that, but I was under the impression that it's fine to do free_page(paddr + offset_in_page) since the offset is within the page, and its corresponding struct page can still be found when being freed. Please let me know if this thought is wrong and I will submit another version. > > -Kees > >> @@ -318,7 +318,7 @@ static ssize_t direct_entry(struct file *f, const char __user *user_buf, >> } >> /* NULL-terminate and remove enter */ >> buf[count] = '\0'; >> - strim(buf); >> + buf = strim(buf); >> >> crashtype = find_crashtype(buf); >> free_page((unsigned long) buf); >> -- >> 2.25.1 >> >
On Fri, Aug 18, 2023 at 10:39:06AM +0800, GONG, Ruiqi wrote: > > On 2023/08/18 0:55, Kees Cook wrote: > > On Thu, Aug 17, 2023 at 10:21:17PM +0800, GONG, Ruiqi wrote: > >> From: "GONG, Ruiqi" <gongruiqi1@huawei.com> > >> > >> Make use of the return value of strim() to achieve left-trim as well as > >> right-trim, which prevents the following unusual fail case: > >> > >> # echo " EXCEPTION" > /sys/kernel/debug/provoke-crash/DIRECT > >> sh: write error: Invalid argument ... > >> /* NULL-terminate and remove enter */ > >> buf[count] = '\0'; > >> - strim(buf); > >> + buf = strim(buf); > >> > >> crashtype = find_crashtype(buf); > >> free_page((unsigned long)buf); > > > > Will free_page() still work in this case, though? The address won't > > match the allocation any more... > > Yes I noticed that, but I was under the impression that it's fine to do > free_page(paddr + offset_in_page) since the offset is within the page, > and its corresponding struct page can still be found when being freed. > Please let me know if this thought is wrong and I will submit another > version. The question is rather why you think this patch makes any sense at all. Nobody is doing what you described above - hence there is no problem. The comments in the code even say strim() is used to remove the trailing '\n'. If anybody passes a string with whitespace at the beginning then that's just a user error. There really is no point in patches like this.
© 2016 - 2025 Red Hat, Inc.