SCSI: fix bug in scsi_dev_info_list matching

The "compatible" matching algorithm used for looking up old-style
blacklist entries in a scsi_dev_info_list is buggy.  The core of the
algorithm looks like this:

		if (memcmp(devinfo->vendor, vendor,
			    min(max, strlen(devinfo->vendor))))
			/* not a match */

where max is the length of the device's vendor string after leading
spaces have been removed but trailing spaces have not.  Because of the
min() computation, either entry could be a proper substring of the
other and the code would still think that they match.

In the case originally reported, the device's vendor and product
strings were "Inateck " and "                ".  These matched against
the following entry in the global device list:

	{"", "Scanner", "1.80", BLIST_NOLUN}

because "" is a substring of "Inateck " and "" (the result of removing
leading spaces from the device's product string) is a substring of
"Scanner".  The mistaken match prevented the system from scanning and
finding the device's second Logical Unit.

This patch fixes the problem by making two changes.  First, the code
for leading-space removal is hoisted out of the loop.  (This means it
will sometimes run unnecessarily, but since a large percentage of all
lookups involve the "compatible" entries in global device list, this
should be an overall improvement.)  Second and more importantly, the
patch removes trailing spaces and adds a check to verify that the two
resulting strings are exactly the same length.  This prevents matches
where one entry is a proper substring of the other.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Giulio Bernardi <ugilio@gmail.com>
Tested-by: Giulio Bernardi <ugilio@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>

0 files changed, 0 insertions, 0 deletions