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
| ||
|
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?
Powered by blists - more mailing lists