Bug 140616
| Summary: | RHEL3 PATCH dev.c: clear SIOCGIFHWADDR buffer if !dev->addr_len | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | jordan hargrave <jordan_hargrave> | ||||
| Component: | kernel | Assignee: | David Miller <davem> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | peterm, petrides, riel, wwlinuxengineering | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | RHEL3 U5 beta | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-05-18 13:28:41 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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.
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;
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. http://rhn.redhat.com/errata/RHSA-2005-294.html |
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: