| Message ID | 20180829144923.6p2omsbe2s343wea@kili.mountain (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | ieee802154: mcr20a: read out of bounds in mcr20a_set_channel() | expand |
On Wed, Aug 29, 2018 at 07:50:51PM +0200, Xue Liu wrote: > Hello Dan, > > > On Wed, 29 Aug 2018 at 16:49, Dan Carpenter <dan.carpenter@oracle.com> > wrote: > > > The "channel" variable can be any u8 value. We need to make sure we > > don't read outside of the PLL_INT[] or PLL_FRAC[] arrays. > > > I think the “channel” variable can not be any u8 value. This values is > already checked before set_channel function is called. > https://github.com/torvalds/linux/blob/master/net/ieee802154/nl802154.c#L978 Oh... Hm... I should have reviewed more carefully. This patch isn't correct. But there may still be a bug. What Smatch is worried about is the other call tree: ieee802154_start_req() calls (struct ieee802154_mlme_ops)->start_req -> mac802154_mlme_start_req() -> mac802154_dev_set_page_channel() -> drv_set_channel() calls local->ops->set_channel(&local->hw, page, channel); -> mcr20a_set_channel() So maybe we could move the check from nl802154_set_channel() to drv_set_channel() so channel is checked on both call trees. regards, dan carpenter
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c index e428277781ac..4f41d1d3588e 100644 --- a/drivers/net/ieee802154/mcr20a.c +++ b/drivers/net/ieee802154/mcr20a.c @@ -512,6 +512,9 @@ mcr20a_set_channel(struct ieee802154_hw *hw, u8 page, u8 channel) dev_dbg(printdev(lp), "%s\n", __func__); + if (channel < 11 || channel - 11 >= ARRAY_SIZE(PLL_INT)) + return -EINVAL; + /* freqency = ((PLL_INT+64) + (PLL_FRAC/65536)) * 32 MHz */ ret = regmap_write(lp->regmap_dar, DAR_PLL_INT0, PLL_INT[channel - 11]); if (ret)
The "channel" variable can be any u8 value. We need to make sure we don't read outside of the PLL_INT[] or PLL_FRAC[] arrays. Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> --- This patch is obviously harmless, but it's from static analysis. I'm pretty sure this is required, but I can't swear.