Le mardi 05 juin 2018 à 10:36:31 (+0300), Dan Carpenter a écrit :
> On Mon, Jun 04, 2018 at 09:32:50PM +0200, Thibaut Robert wrote:
> > Le mercredi 30 mai 2018 à 14:17:25 (+0300), Dan Carpenter a écrit :
> > > On Tue, May 29, 2018 at 09:11:43PM +0200, Thibaut Robert wrote:
> > > > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > index e248702ee519..745bf5ca2622 100644
> > > > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > @@ -1431,7 +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device *dev, u8 *buff, u32 size)
> > > >
> > > > freq = ieee80211_channel_to_frequency(curr_channel, NL80211_BAND_2GHZ);
> > > >
> > > > - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > > > + if (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> > >
> > > "buff" comes from the network, it's going to be little endian, not cpu
> > > endian. The rest of the function treats it as CPU endian but I'm pretty
> > > sure it's wrong...
> > buff comes from the network but we are looking at single byte here.
> > ieee80211_is_action expects an le16, so we I added this to extend an u8
> > to an le16. Is this incorrect ?
> >
> > Or maybe we the buff has the second byte ? but that I can't tell.
>
> You raise a good point that I hadn't seen. The original code is clearly
> buggy. But your fix isn't correct either... The other thing to
> consider is that cpu_to_le16() is basically a cast to u16 on x86 so it's
> a no-op here.
The sparse warning is clearly spotting a real issue. I tried to at least
have big endian handle correctly the 0-255 case. I am willing to drop
the change (since I agree it's not very satisfying and will mask an issue),
but may I ask you to explain how it is wrong ? How would you correctly expand
an u8 to __le16 ? I think in big endian we need to swap the bytes.
>
> Really the right thing is to not treat buff as an array of u8 but a
> struct. The code assumes that frame_type is 0-255 but probably it's
> supposed to go up to U16_MAX.
>
> struct whatever {
> __le16 frame_type;
> ...
>
> There probably is already a struct like that, but I don't know what it
> is. I don't know this code at all, I'm just guessing.
>
I was thinking the same. I don't know whether this buf contains a
standard struct or something hw-specific. I'll try to dig further and
submit a separate patch if I can. Maybe Aditya can give more information
?
> regards,
> dan carpenter
>
Regards,
Thibaut
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
