linux-kernel - Re: [PATCH] staging: line6: fix possible overrun

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: <20140429152616.GA2316@mguzik.redhat.com>
Date:	Tue, 29 Apr 2014 17:26:17 +0200
From:	Mateusz Guzik <mguzik@...hat.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
	Laurent Navet <laurent.navet@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: line6: fix possible overrun

On Tue, Apr 29, 2014 at 04:47:11PM +0200, Takashi Iwai wrote:
> At Mon, 28 Apr 2014 01:44:25 +0300,
> Dan Carpenter wrote:
> > 
> > On Sun, Apr 27, 2014 at 10:00:43PM +0200, Mateusz Guzik wrote:
> > > > >  and a WARN_ON + -EINVAL in line6_init_audio to catch future
> > > > >  offenders.
> > > > 
> > > > Returning -EINVAL is a bad idea because it would break the driver
> > > > completely and make it unusable.
> > > > 
> > > 
> > > Well I would vote for returning the error anyway.
> > 
> > I'm trying to be polite, but you are talking about adding regressions
> > deliberately...
> > 
> > It's very rare for people to deliberately add regressions to the kernel.
> > I have only seen it one time before.
> 
> I don't think Dan would be against returning -EINVAL if all the
> offender codes have been fixed (e.g. truncating strings to fit with
> the fixed arrays) at first.  Then it'd be a good help to catch any
> future bugs.  But, having -EINVAL without fixing the caller side means
> essentially that you're introducing the breakage intentionally
> although you know it certainly breaks, which is obviously bad.
> 
> 

We clearly have a serious miscommunication here (and apparently it
started with me not addressing the concern of complete driver breakage).

line6_init_audio consumers have to be fixed first, no doubt about that.

I was only commenting on catching *future* offenders, which I thought
would implictly mean *afterwards*.

With that in mind it would seem we are in agreement after all. :-)

As far getting this done maybe OP is interested.

-- 
Mateusz Guzik
--
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/