linux-kernel - Re: [butterfly_attach] WARNING: CPU: 0 PID: 198 at fs/sysfs/dir.c:31 sysfs_warn

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: <20171108111750.lpr7vuhf37znxmsn@sirena.co.uk>
Date:   Wed, 8 Nov 2017 11:17:50 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Fengguang Wu <fengguang.wu@...el.com>, linux-spi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [butterfly_attach] WARNING: CPU: 0 PID: 198 at fs/sysfs/dir.c:31
 sysfs_warn_dup+0x71/0x97

On Tue, Nov 07, 2017 at 08:49:46AM -0800, Linus Torvalds wrote:
> On Tue, Nov 7, 2017 at 2:24 AM, Fengguang Wu <fengguang.wu@...el.com> wrote:

> > FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.

> Yeah, very doubtful. Nobody has touched that spi-butterfly driver in
> about two years.

Indeed.  I'm not super convinced anyone who actually has the hardware
has touched the driver since David Brownell was maintaining SPI, all the
changes since then seem pretty mechanical.

> > [   13.141240] sysfs: cannot create duplicate filename '/devices/pnp0/00:04/spi_master/spi42'
> > [   13.142495] ------------[ cut here ]------------

> I'm not sure why that driver even gets initialized under qemu. I'm
> assuming it just tries to attach to any parport.

Yes, if there's any mechanism for constraining what it attaches to it's
in the parport subsysetm.  This simply provides an attach method which
the parport subsystem looks like it calls on any parport in the system.
I'm a little confused about how it ends up getting registered multiple
times but that looks like it should be something in paport (I noticed
some stuff about allowing multiple devices on one port).

> Mark, should it have a stricter check perhaps? Or should this driver
> perhaps simply not be loaded by the zeroday robot?

Loading parallel port client drivers (or other semi-enumerable drivers)
seems like a recipe for trouble.  In this case there's never been any
code there that attempts to work out if there's actually a butterfy
device on the parport, just a REVISIT comment in the code which isn't
much help.  Looking at the docs for the driver it's intended to control
an AVR32 microcontroller reference board running some custom program
(with instructions on how to make the cable!) so I don't hold out much
hope.

I'm tempted to just remove the driver though I fear it might have some
actual users for industrial processes still.  

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)