Bug 140616 - RHEL3 PATCH dev.c: clear SIOCGIFHWADDR buffer if !dev->addr_len
RHEL3 PATCH dev.c: clear SIOCGIFHWADDR buffer if !dev->addr_len
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-23 15:51 EST by jordan hargrave
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHEL3 U5 beta
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-18 09:28:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for /net/core/dev.c (644 bytes, patch)
2004-11-23 16:35 EST, jordan hargrave
no flags Details | Diff

  None (edit)
Description jordan hargrave 2004-11-23 15:51:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET 
CLR 1.1.4322)

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 
field.

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):


How reproducible:
Always

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

Additional info:
Comment 1 jordan hargrave 2004-11-23 16:35:38 EST
Created attachment 107344 [details]
Patch for /net/core/dev.c
Comment 2 David Miller 2004-11-23 18:55:42 EST
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.
Comment 3 Matt Domsch 2004-11-24 08:48:00 EST
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.


                case SIOCGIFHWADDR:
                        memcpy(ifr->ifr_hwaddr.sa_data,dev->dev_addr,
                               min(sizeof ifr->ifr_hwaddr.sa_data,
(size_t) dev->addr_len));
                        ifr->ifr_hwaddr.sa_family=dev->type;
                        return 0;
Comment 4 David Miller 2004-11-24 18:02:08 EST
My bad, you're of course right.
I'll submit this patch for inclusion.
Comment 5 John W. Linville 2004-11-29 09:37:20 EST
*** Bug 140585 has been marked as a duplicate of this bug. ***
Comment 6 Matt Domsch 2004-12-08 14:26:37 EST
As this isn't in 2.4.21-27.EL (U4 release candidate) kernel, can we
expect to see this in U5?
Comment 7 Ernie Petrides 2004-12-08 15:55:23 EST
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.
Comment 8 Ernie Petrides 2004-12-23 18:14:45 EST
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).
Comment 9 jordan hargrave 2005-03-29 17:58:14 EST
This is fixed in U5 Beta1
Comment 10 Ernie Petrides 2005-04-07 15:37:10 EDT
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.
Comment 11 Tim Powers 2005-05-18 09:28:41 EDT
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.

http://rhn.redhat.com/errata/RHSA-2005-294.html

Note You need to log in before you can comment on or make changes to this bug.