linux-kernel - Re: gadgetfs broken since 7f7f25e8

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]

Date:	Mon, 02 Mar 2015 15:31:11 +0100
From:	Alexander Holler <holler@...oftware.de>
To:	Al Viro <viro@...IV.linux.org.uk>,
	Richard Weinberger <richard.weinberger@...il.com>
CC:	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: gadgetfs broken since 7f7f25e8

Am 02.03.2015 um 14:02 schrieb Alexander Holler:
> Am 02.03.2015 um 12:39 schrieb Alexander Holler:
>> Am 02.03.2015 um 11:20 schrieb Al Viro:
>>> On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:
>>>> On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler
>>>> <holler@...oftware.de> wrote:
>>>>> Hello.
>>>>>
>>>>> Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with
>>>>> 3.16) broke
>>>>> dynamic changing of file_operations->[read|write].
>>>>>
>>>>> At least gadgetfs is a victim.

Just for your amusement and as an example:

This bug lead to me to examine and search bugs in the userland piece 
I've tried to use and ended up in around

===
aholler@...topahbt ~/Source/USBProxy.git/src $ PAGER= git diff 
7d2506648e3404bf7070bae6ab8da4a702ed093c --stat
  doc/gadgetfs_kernel_above_3.15.patch     |  50 
+++++++++++++++++++++++++++++++++++++++++++++++
  src/Plugins/Hosts/GadgetFS_helpers.c     |   4 ++--
  src/Plugins/Hosts/HostProxy_GadgetFS.cpp |  12 ++++++++++++
  src/debian/header-check.c                |   1 -
  src/lib/CMakeLists.txt                   |   2 --
  src/lib/ConfigParser.cpp                 |   9 +++------
  src/lib/ConfigParser.h                   |   2 +-
  src/lib/FDInfo.c                         |   2 +-
  src/lib/HaltSignal.c                     |  54 
---------------------------------------------------
  src/lib/HaltSignal.h                     |  19 ------------------
  src/lib/Injector.cpp                     |  23 +++++-----------------
  src/lib/Injector.h                       |  11 +++++++----
  src/lib/Manager.cpp                      | 122 
+++++++++++++++++++++++++++++++++++++++++++-----------------------------------------------------------------------
  src/lib/Manager.h                        |  15 +++++++-------
  src/lib/PluginManager.cpp                |  47 
+++++++++++++++++++++++++++++++++-----------
  src/lib/Proxy.h                          |  12 ++++++++++++
  src/lib/RelayReader.cpp                  |  39 
++++++++++++-------------------------
  src/lib/RelayReader.h                    |   9 ++++++---
  src/lib/RelayWriter.cpp                  |  69 
++++++++++++++++------------------------------------------------
  src/lib/RelayWriter.h                    |   8 +++++---
  src/tools/usb-mitm.cpp                   |   2 --
  21 files changed, 223 insertions(+), 289 deletions(-)
  ===

without counting at least a dozen patches I did on that userland piece 
before those which are counted in the above stat. All in order to find 
the bug.

So, you can see, I've already spend some hours before I've dived into 
the kernel to search for the bug. Of course, the problem in the kernel 
is innocent for all the problems I've found in userland which lead me to 
the assumption that the -EINVAL returned from a read() after a poll() is 
because of some problem in userspace (like memory or stack corruption).

Just in case someone thinks I'm lazy because I don't want to rewrite 
gadgetfs and deal with kernel maintainers.

Regards,

Alexander Holler
--
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/