Bug 126396 - CAN-2004-0587 Bad permissions on qla* drivers
CAN-2004-0587 Bad permissions on qla* drivers
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Coughlan
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2004-06-21 04:35 EDT by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-03 18:36:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch from SUSE (will need modification for other cases) (2.08 KB, patch)
2004-06-21 04:35 EDT, Mark J. Cox (Product Security)
no flags Details | Diff

  None (edit)
Description Mark J. Cox (Product Security) 2004-06-21 04:35:02 EDT
A device permission issue was reported in SUSE Linux on May 5th 2004
affecting '/proc/scsi/qla2300/HbaApiNode' file. A local user could
potentially use this to cause a denial of service.

On Red Hat Enterprise Linux 3 this may also affect
drivers/addon/qla2200_60600b11/qla2x00.c and 
drivers/addon/qla2200/qla2x00.c although these are unsupported.

Patch from SUSE attached.
Comment 1 Mark J. Cox (Product Security) 2004-06-21 04:35:45 EDT
Created attachment 101285 [details]
Patch from SUSE (will need modification for other cases)
Comment 2 Ernie Petrides 2004-06-21 19:42:21 EDT
A fix for this problem was committed to the RHEL3 U3 this past
Saturday evening (in kernel version 2.4.21-15.14.EL).
Comment 3 Mark J. Cox (Product Security) 2004-07-05 05:05:56 EDT
Confirmed, linux-2.4.9-qla2200.patch now corrects this, however
Patch8081: linux-2.4.9-qla2200-backup-60702RH2.patch still contains a
couple of proc_mknod(APIDEV_NODE, 0777+S_IFCHR... calls which look to
be the same issue.
Comment 4 Ernie Petrides 2004-07-12 14:32:07 EDT
Mark, our strategy-to-date with backup drivers is that they should
exactly match the version of the driver in the prior update.  No one
should actually be using the backup driver.  It is retained solely
for the hypothetical scenario that a driver update causes a serious
regression, in which case a customer could fall back to using the
prior version (which would require manual intervention).

Since customers automatically start using the new driver after
their systems are updated, would it be okay with you if we simply
leave the old backup driver as is?
Comment 5 Mark J. Cox (Product Security) 2004-07-13 03:48:04 EDT
Comment 6 Ernie Petrides 2004-07-13 15:06:00 EDT
Ok, I'll put this back in MODIFIED state (fixed in U3).  I also
intend to pull the fix into the next security errata (in the E3
stream), and I will update this bug again after committing the
fix there.
Comment 7 Ernie Petrides 2004-07-31 01:57:38 EDT
A fix for this problem has also been committed to the RHEL3 E3
patch pool (in kernel version 2.4.21-15.0.4.EL).
Comment 8 Mark J. Cox (Product Security) 2004-08-03 18:36:27 EDT
An errata 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.


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