linux-kernel - Re: [PATCH] staging: lustre: fix sparse warning on LPROC_SEQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <D0A87E89.CDFB9%andreas.dilger@intel.com>
Date:	Sat, 6 Dec 2014 17:05:14 +0000
From:	"Dilger, Andreas" <andreas.dilger@...el.com>
To:	Tristan Lelong <tristan@...ong.xyz>,
	Greg KH <gregkh@...uxfoundation.org>
CC:	"Drokin, Oleg" <oleg.drokin@...el.com>,
	"askb23@...il.com" <askb23@...il.com>,
	"Hammond, John" <john.hammond@...el.com>,
	"gdonald@...il.com" <gdonald@...il.com>,
	"anhlq2110@...il.com" <anhlq2110@...il.com>,
	"fabio.falzoi84@...il.com" <fabio.falzoi84@...il.com>,
	"oort10@...il.com" <oort10@...il.com>,
	"agimenez@...valve.es" <agimenez@...valve.es>,
	"rupran@...server.de" <rupran@...server.de>,
	"surya.seetharaman9@...il.com" <surya.seetharaman9@...il.com>,
	"Julia.Lawall@...6.fr" <Julia.Lawall@...6.fr>,
	"joe@...ches.com" <joe@...ches.com>,
	"a.terekhov@...il.com" <a.terekhov@...il.com>,
	"vthakkar1994@...il.com" <vthakkar1994@...il.com>,
	"amk@...y.com" <amk@...y.com>,
	"srikrishanmalik@...il.com" <srikrishanmalik@...il.com>,
	"rd@...ekdostal.com" <rd@...ekdostal.com>,
	"bergwolf@...il.com" <bergwolf@...il.com>,
	"dan.carpenter@...cle.com" <dan.carpenter@...cle.com>,
	"Gortmaker, Paul (Wind River)" <paul.gortmaker@...driver.com>,
	"tapaswenipathak@...il.com" <tapaswenipathak@...il.com>,
	"email@...istophjaeger.info" <email@...istophjaeger.info>,
	"uja.ornl@...il.com" <uja.ornl@...il.com>,
	"brilliantov@...ox.ru" <brilliantov@...ox.ru>,
	"Eremin, Dmitry" <dmitry.eremin@...el.com>,
	"HPDD-discuss@...ts.01.org" <HPDD-discuss@...ts.01.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] staging: lustre: fix sparse warning on LPROC_SEQ_FOPS
 macros

On 2014/12/05, 3:41 PM, "Tristan Lelong" <tristan@...ong.xyz> wrote:

>On Fri, Dec 05, 2014 at 01:27:23PM -0800, Greg KH wrote:
>> On Fri, Dec 05, 2014 at 12:03:47AM -0800, Tristan Lelong wrote:
>> >  static ssize_t
>> > -fld_proc_hash_seq_write(struct file *file, const char *buffer,
>> > -			size_t count, loff_t *off)
>> > +fld_proc_hash_seq_write(struct file *file,
>> > +				const char __user *buffer,
>> > +				size_t count, loff_t *off)
>> >  {
>> >  	struct lu_client_fld *fld;
>> >  	struct lu_fld_hash *hash = NULL;
>> > +	char name[80];
>> >  	int i;
>> >  
>> > +	if (count > 80)
>> > +		return -ENAMETOOLONG;
>> > +
>> > +	if (copy_from_user(name, buffer, count) != 0)
>> > +		return -EFAULT;
>> 
>> How was this code ever working before?
>
>I have no idea, and was actually surprised that this was there.
>
>> 
>> And I know Joe asked, but how do you know that 80 is ok?  And why on the
>> stack?
>
>80 is the sizeof(struct lu_fld_hash.fh_name) and there is no define for
>that.  A few other structure members are using this 80 value internally,
>and as I told Joe, I will analyze if they are all related and submit a
>patch to use a define instead.

Sorry, but I don't see where you get 80 from?  fh_name is declared as a
"const char *", and initialized in the declaration of fld_hash[].  I'd
thought to reply that sizeof(fh_name) would even be better than a #define,
but sizeof(const char *) doesn't actually make sense.

The longest declared fh_name is 4 characters, but I'm not sure of an easy
way to determine this at compile time.  I guess one option is to change
the declaration of struct lu_fld_hash to use "const char fh_name[4];" and
then use sizeof(fh_name), but I don't know if that is better than just
declaring a small buffer (8 chars) for this usage.  IMHO that is small
enough to fit on the stack, since it is at the top of a very short
callchain (userspace->sys_write->vfs_write->fld_proc_hash_seq_write())
that just saves the value so the chance of stack overflow is basically nil.

>> 
>> Shouldn't you just compare count to strlen(fld_hash[i].fh_name)? like
>>you
>> do later on?
>> 
>
>This is actually done in the for loop already. I first compare with the
>maximum size, then the loop use the strlen of each entries in the table,
>and finally does the strncmp.
>
>> 
>> Anyway, I don't like large stack variables like this, can you make it
>> dynamic instead?
>> 
>
>I can definitely do this with a kmalloc, I'll submit a v2 tonight.
>
>Thanks
>


Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/