linux-kernel - Possible unwanted behaviour in configfs

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-next>] [day] [month] [year] [list]

Message-ID: <CAFDyS3MwuarsJVnR8E1OQjCF1vN4jZSs84zq-8sMysaOkQyS1g@mail.gmail.com>
Date:	Sat, 25 Jun 2016 12:43:34 +0300
From:	Tal Shorer <tal.shorer@...il.com>
To:	"<linux-kernel@...r.kernel.org>" <linux-kernel@...r.kernel.org>,
	Joel Becker <jlbec@...lplan.org>, hch@....de
Subject: Possible unwanted behaviour in configfs

Hey,
I encountered a possible unwanted behaviour in the way configfs
handles read() on items' attributes.
The show() function is called only once (which is good) on the first
time the user attempts to read from the file. If show() returns an
error that error is returned to the user. However, if the user calls
read() again, no data is copied (good) and a value of zero is
returned.
This is especially evident when using busybox's cat utility, which
first attempts sendfile64() and if that fails falls back to read(),
giving the user the impression that reading the attribute was
successful but no data was returned.

I traced this to the function configfs_read_file in fs/configfs/file.c
and have two fixes in mind:
1. In fill_read_buffer(), If an error is returned by show(), don't set
buffer->needs_read_fill to zero, making the next read() call show()
again and either get an error or data.
2. Add an "err" field to struct configfs_buffer and keep the returned
error from show() there. Any additional read() on this file will
return this error.

Any thoughts?