Red Hat Bugzilla – Bug 140616
RHEL3 PATCH dev.c: clear SIOCGIFHWADDR buffer if !dev->addr_len
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET
Description of problem:
Issuing a SIOCGIFHWADDR on a ppp connection does not clear the
address buffer, causing garbage data to be reported as the HWADDR
If dev->dev_addr is zero, then the memcpy() never takes place, and the
same data that was in the caller's buffer is still in the caller's
buffer on successful return. The caller can't know that the data in
its buffer isn't the right answer. So, if dev->dev_dev_addr == 0,
clear the buffer before returning success.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install RHEL3 kernel
2.Create ppp connection
3.Initialize mac addr field with random data, issue SIOCGIFHWADDR on
ppp interface. HWADDR field is not updated
Actual Results: Garbage data appears in the HWADDR field
Expected Results: Field should be zeroed out
Created attachment 107344 [details]
Patch for /net/core/dev.c
Patch not needed, the problem only exists in 2.6.x kernels.
In 2.4.x, we always perform the memcpy with a length of
MAX_ADDR_LEN from dev->dev_addr which will be all zeros
for devices with zero dev->addr_len.
DaveM, that's true for upstream, but not for RHEL3 kernels. Here's
what 2.4.21-26.EL has, must have been backported from 2.6 at some point.
My bad, you're of course right.
I'll submit this patch for inclusion.
*** Bug 140585 has been marked as a duplicate of this bug. ***
As this isn't in 2.4.21-27.EL (U4 release candidate) kernel, can we
expect to see this in U5?
The patch in comment #1 is on target for inclusion in U5. I'll
update this bug report when the fix has been committed to CVS.
A fix for this problem has just been committed to the RHEL3 U5
patch pool this evening (in kernel version 2.4.21-27.5.EL).
This is fixed in U5 Beta1
Thanks for the verification, Jordan. I'm reverting the state of this BZ
to MODIFIED until U5 is actually released. When that happens, the state
will be automatically changed to CLOSED/ERRATA.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.