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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 23 Jan 2007 11:06:31 -0800
From:	Joel Becker <Joel.Becker@...cle.com>
To:	Michael Noisternig <mnoist@...y.sbg.ac.at>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: configfs: return value for drop_item()/make_item()?

On Tue, Jan 23, 2007 at 02:49:59PM +0100, Michael Noisternig wrote:
> Sorry, I wasn't clear. I meant that it's not possible to let the user 
> create the parent directory via mkdir(2) within sysfs. I.e.
> # mkdir object  <-- create object/, configfs only
> # ls object
> type
> # echo b > object/type  <-- create b/, sysfs only
> # ls object
> type
> b/
> I cannot have both, sysfs and configfs functionality, within the same 
> module configuration file system tree.

	No, you can't have sysfs and configfs functionality in the same
exact portion of the tree.  But you can use both sysfs and configfs at
the same time in your driver.  The different parts will appear in the
different trees.  Up to you.

> 1. Is there any guarantee that strings passed to struct 
> configfs_item_operations->store_attribute are 0-terminated? If not, 
> there's not only potential for buffer overflows, but there already is - 
> in configfs_example.c, using simple_strtoul().

	There is no guarantee, but that's a bug.  The attribute handling
code came from sysfs.  I assume the initial assumption was that since
you can only copy a page, it's OK.  Clearly not the case.  sysfs fixed
this in October (commit 035ed7a49447bc8e15d4d9316fc6a359b2d94333).  I'll
be porting that over.  Thanks for noticing!

> 2. A minor one: I realize that the CONFIGFS_ITEM_NAME_LEN value of 20 is 
> taken over from sysfs, but in configfs a config_group now has 68 bytes 
> of size, and assuming that many times one would simply kmalloc a simple 
> struct config_group (without extending it) this would result in a waste 
> of 60 bytes per malloc. Do you want to keep that #define or reduce it to 
> 16? Just a thought...

	Hmm, interesting.  I'll look at that as well.

Joel

-- 

Life's Little Instruction Book #511

	"Call your mother."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ