public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.6.9-rcX cdrom.c is subject to "chaotic" behaviour
@ 2004-08-25 10:11 Andy Polyakov
  2004-08-26 10:14 ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: Andy Polyakov @ 2004-08-25 10:11 UTC (permalink / raw)
  To: linux-kernel, axboe, samuel.thibault

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-08-28  9:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-25 10:11 2.6.9-rcX cdrom.c is subject to "chaotic" behaviour Andy Polyakov
2004-08-26 10:14 ` Andrew Morton
2004-08-28  9:46   ` Andy Polyakov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox