[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201709302201.27017@pali>
Date: Sat, 30 Sep 2017 22:01:26 +0200
From: Pali Rohár <pali.rohar@...il.com>
To: Mario.Limonciello@...l.com
Cc: dvhart@...radead.org, andy.shevchenko@...il.com,
linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
luto@...nel.org, quasisec@...gle.com
Subject: Re: [PATCH v3 3/8] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check
On Saturday 30 September 2017 21:48:39 Mario.Limonciello@...l.com wrote:
> > > +/*
> >
> > > + * Descriptor buffer is 128 byte long and contains:
> > ...
> >
> > > + if (obj->buffer.length != 128) {
> > > + dev_err(&wdev->dev,
> > > + "Dell descriptor buffer has invalid length (%d)\n",
> > > + obj->buffer.length);
> >
> > This seems odd. We call it an error (not a warning) if != 128, but
> > we only abort and return an error if it's < 16.
> >
> > If it's an error, we should return an error code, if anything above
> > 16 is acceptable but 128 is preferred, the above should be a
> > warning at best. (this scenario seems unlikely).
>
> Hopefully the original author can speak up to the intentions here. I
> would feel that it should have errored out if it wasn't expected
> length too.
Code below access first 16 bytes of buffer. Therefore to prevent buffer
overflow check for 16 bytes is needed.
But IIRC we decided to do not throw error and continue driver loading
even when buffer length is not 128 (as expected by some Dell
documentation) as it could be possible regression because driver itself
does not depend on buffer length.
> > > + if (obj->buffer.length < 16) {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > > + }
> > > + desc_buffer = (u32 *)obj->buffer.pointer;
> > > +
> > > + if (desc_buffer[0] != 0x4C4C4544 && desc_buffer[1] !=
> > > 0x494D5720)
--
Pali Rohár
pali.rohar@...il.com
Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists