2.6.9-rcX cdrom.c is subject to "chaotic" behaviour

[Andy Polyakov]

As per 
http://marc.theaimsgroup.com/?l=bk-commits-head&m=109330228416908&w=2, 
cdrom.c becomes subject to chaotic behavior. The culprit is newly 
introduced if-statement such as following:

if (cdrom_get_disc_info(cdi, &di) < offsetof(typeof(di),disc_type))

The catch is that cdrom_get_disc_info returns signed value, most notably 
negative one upon error, while the offsetof on the other hand is 
unsigned. When signed and unsigned values are compared, signed one is 
treated as unsigned and therefore in case of error condition in 
cdrom_get_disc_info the if-statement is doomed to be evaluated false, 
which in turn results in random values from the stack being evaluated 
further down.

There is another subtle problem which was there and was modified in the 
same code commit:

-	if ((ret = cdrom_get_disc_info(cdi, &di)))
+	if ((ret = cdrom_get_disc_info(cdi, &di))
+			< offsetof(typeof(di), last_track_msb)
+			+ sizeof(di.last_track_msb))
 		goto use_last_written;

 	last_track = (di.last_track_msb << 8) | di.last_track_lsb;

last_track_msb was introduced in one of later MMC specifications. 
Previously the problem with the cdrom.c code was that the last_track_msb 
value might turn uninitialized when you talk to elder units, while now 
last_track_lsb value returned by elder units is simply disregarded for 
no valid reason. The more appropriate way to deal with the problem is:

	memset (&di,0,sizeof(di));
	if ((ret = cdrom_get_disc_info(cdi, &di))
			< (int)(offsetof(typeof(di), last_track_lsb)
			+ sizeof(di.last_track_lsb)))
 		goto use_last_written;

	last_track = (di.last_track_msb << 8) | di.last_track_lsb;

This way last_track_msb is forced to zero for elder units and last_track 
is maintained sane.

Further down we see:

        /* if this track is blank, try the previous. */
        if (ti.blank) {
                last_track--;
                ti_size = cdrom_get_track_info(cdi, last_track, 1, &ti);
        }

What if there is no previous track? It might turn out that we never get 
here, because if-statement elsewhere, and check for last_track>1 will be 
redundant. But what if the "elsewhere" will be changed at some later 
point? My point is that IMO check for last_track>1 is more than 
appropriate here.

If you prefer the above findings to be expressed in form of patch, then 
I might have some time only this weekend (unfortunately). A.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/