[Intel-wired-lan] [PATCH v1 net-next 2/2] igb: support SIOCSMIIREG

Rustad, Mark D mark.d.rustad at intel.com
Thu May 7 20:46:15 UTC 2015


> On May 7, 2015, at 10:52 AM, Alexander Duyck <alexander.duyck at gmail.com> wrote:
> 
>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
>> index 720b785..1071a71 100644
>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>> @@ -7141,6 +7141,11 @@ static int igb_mii_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
>>  			return -EIO;
>>  		break;
>>  	case SIOCSMIIREG:
>> +		adapter->hw.phy.addr = data->phy_id;
>> +		if (igb_write_phy_reg(&adapter->hw, data->reg_num & 0x1F,
>> +				      data->val_in))
>> +			return -EIO;
>> +		break;
>>  	default:
>>  		return -EOPNOTSUPP;
>>  	}
> 
> How and why is this being used?  From what I can tell it looks like it is an easy way to break any of the existing interfaces if it is misused since all you would need to do is specify a phy address that doesn't match the existing PHY in the system and then you would likely lose link, or possibly mess up the configuration on the system requiring.
> 
> I suspect this is a back door for some piece of user space code that is being given far more permission than it should be.

I don't know about a back door, but the real problem is that it has a
side-effect of changing the saved value of the phy addr. That is clearly
a problem and can't be allowed.

For the phylib stuff to really work as intended, the igb_write_phy_reg
really should take the phy address as a parameter instead of getting
the value from the structure itself. Or a new function should be
defined that has that interface.

--
Mark Rustad, Networking Division, Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20150507/124da355/attachment.asc>


More information about the Intel-wired-lan mailing list