lkml.org 
[lkml]   [2004]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.6.9-rcX cdrom.c is subject to "chaotic" behaviour
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:1.698 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site