Bug 137648 - RHEL4 PATCH dev.c: clear SIOCGIFHWADDR buffer if !dev->addr_len
Summary: RHEL4 PATCH dev.c: clear SIOCGIFHWADDR buffer if !dev->addr_len
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: John W. Linville
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 135876
TreeView+ depends on / blocked
 
Reported: 2004-10-29 21:52 UTC by Matt Domsch
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-24 00:13:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
net-core-dev.c.patch (644 bytes, patch)
2004-10-29 21:53 UTC, Matt Domsch
no flags Details | Diff
net-core-dev.c-2.6.patch (805 bytes, patch)
2004-11-01 21:43 UTC, Matt Domsch
no flags Details | Diff

Description Matt Domsch 2004-10-29 21:52:27 UTC
Description of problem:
From: Matt Domsch <Matt_Domsch@Dell.com>
To: netdev@oss.sgi.com

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.

Thanks,
Matt


Version-Release number of selected component (if applicable):
2.6.9-rc1 and earlier 2.6 variants

Comment 1 Matt Domsch 2004-10-29 21:53:38 UTC
Created attachment 105967 [details]
net-core-dev.c.patch

Patch as submitted to netdev@oss.sgi.com for 2.6

Comment 3 Matt Domsch 2004-11-01 21:43:33 UTC
Created attachment 106049 [details]
net-core-dev.c-2.6.patch

Updated patch based on discussion on netdev@oss.sgi.com.
For RHEL4, Red Hat may wish not to include the printk, as there are ~30
applications which will cause that printk to trigger, none of which is really
broken.

Comment 6 Dave Jones 2004-11-04 20:48:53 UTC
fixed in cvs


Comment 7 Matt Domsch 2004-11-10 20:37:00 UTC
FWIW, DaveM applied the first of my patches, not the latter one.  
Which got applied to CVS please?

Comment 8 Dave Jones 2004-11-12 00:37:10 UTC
the one from commment #3 (minus the printk)

Comment 9 Amit Bhutani 2004-11-24 00:13:09 UTC
Verified, patch from #3 minus the printk statement included in kernel 
2.6.9-1.751_EL. Spoke to Matt and he stated that he didn't care much 
for the printk statement in the first place. Closing the issue as 
this patch meets our needs.




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