On Wed, 11 Nov 2020 18:18:31 +0800 Yicong Yang <yangyicong@xxxxxxxxxxxxx> wrote: > Hi, > > Thanks for reviewing this. > > > On 2020/11/11 3:18, Andrew Morton wrote: > > On Tue, 10 Nov 2020 17:25:24 +0800 Yicong Yang <yangyicong@xxxxxxxxxxxxx> wrote: > > > >> The attr->set() receive a value of u64, but simple_strtoll() is used > >> for doing the conversion. It will lead to the error cast if user inputs > >> a negative value. > >> > >> Use kstrtoull() instead of simple_strtoll() to convert a string got > >> from the user to an unsigned value. The former will return '-EINVAL' if > >> it gets a negetive value, but the latter can't handle the situation > >> correctly. > >> > >> ... > >> > >> --- a/fs/libfs.c > >> +++ b/fs/libfs.c > >> @@ -977,7 +977,9 @@ ssize_t simple_attr_write(struct file *file, const char __user *buf, > >> goto out; > >> > >> attr->set_buf[size] = '\0'; > >> - val = simple_strtoll(attr->set_buf, NULL, 0); > >> + ret = kstrtoull(attr->set_buf, 0, &val); > >> + if (ret) > >> + goto out; > >> ret = attr->set(attr->data, val); > >> if (ret == 0) > >> ret = len; /* on success, claim we got the whole input */ > > kstrtoull() takes an `unsigned long long *', but `val' is a u64. > > > > I think this probably works OK on all architectures (ie, no 64-bit > > architectures are using `unsigned long' for u64). But perhaps `val' > > should have type `unsigned long long'? > > the attr->set() takes 'val' as u64, so maybe we can stay it unchanged here > if it works well. Sure. But the compiler will convert an unsigned long long into a u64 quite happily, regardless of how u64 was actually implemented. However the compiler will not convert a `u64 *' into an `unsigned long long *' if the underlying type of u64 happens to be `unsigned long'. It will warn.
