From: Mateusz Guzik <mguzik@redhat.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: tiwai@suse.de, gregkh@linuxfoundation.org,
devel@driverdev.osuosl.org,
Laurent Navet <laurent.navet@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: line6: fix possible overrun
Date: Sun, 27 Apr 2014 22:00:43 +0200 [thread overview]
Message-ID: <20140427200042.GA23846@mguzik.redhat.com> (raw)
In-Reply-To: <20140427173932.GP26890@mwanda>
On Sun, Apr 27, 2014 at 08:39:32PM +0300, Dan Carpenter wrote:
> On Sat, Apr 26, 2014 at 11:59:46PM +0200, Mateusz Guzik wrote:
> > > And sadly enough some of those ->id strings are more than 15 characters
> > > and a NUL which will fit in card->id. So this overflow is real. The
> > > card->shortname is a 32 char array so none of those overflow.
> > >
> > > If we want to sovle the truncation issue then we need to think of
> > > shorter names for BassPODxtLive, BassPODxtPro, PODStudioUX1, and
> > > PODStudioUX2.
> > >
> >
> > In that case I suggest compile time assertions that ids and names fit
>
> That sounds like some magic code which I would love to see. :)
>
Just asserting something on compile time is not a problem.
The kernel has BUILD_BUG_ON macro. I didn't check why, but it doesn't
use _Static_assert. Instead it produces some code which makes it
unusable in this context.
Aforementoined _Static_assert is available at least in gcc and clang and
you can call it outside of any function, e.g.:
_Static_assert(sizeof(meh) < 42, "oh no");
Unfortnately I failed to come up with a macro which would allow me to use
it in the initializer. :/
One could change line6_properties's definition so that it contains
arrays instead of pointers, that would introduce automagic checking and
I don't think memory waste (if any) would be problematic.
> > 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. Something is wrong,
better fix it as it is instead of risking additional bugs resulting
from truncation.
> >
> > As a side note I'm not sure if pod_try_init from drivers/staging/line6/pod.c
> > cleans up properly after failed line6_init_audio.
>
> Yeah. It doesn't seem to clean up at all.
>
--
Mateusz Guzik
next prev parent reply other threads:[~2014-04-27 20:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-26 17:09 [PATCH] staging: line6: fix possible overrun Laurent Navet
2014-04-26 20:47 ` Mateusz Guzik
2014-04-26 21:36 ` Dan Carpenter
2014-04-26 21:59 ` Mateusz Guzik
2014-04-27 17:39 ` Dan Carpenter
2014-04-27 19:05 ` Laurent Navet
2014-04-27 20:00 ` Mateusz Guzik [this message]
2014-04-27 22:44 ` Dan Carpenter
2014-04-29 14:47 ` Takashi Iwai
2014-04-29 15:02 ` Dan Carpenter
2014-04-29 15:26 ` Mateusz Guzik
2014-04-29 17:28 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140427200042.GA23846@mguzik.redhat.com \
--to=mguzik@redhat.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=laurent.navet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.