Subject: Reading past device size (/dev/vnd v.s. /dev/cd)
To: None <tech-kern@NetBSD.org>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 01/20/2006 15:56:24
--GvXjxJ+pjyke8COw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Dear folks,

i've stumbled on a inconsistency when i deliberately tried to read a 
truncated UDF discimage. The image contains a filingsystem with one big 
file that is spanning the whole disc. The truncated discimage i got when 
trying to write a CD too fast :( (or rather cdrecord thought it was smart).

When reading the image from the CD with dd(1) and creating a vnd image from 
it, udf reads the file and at the offset when it reaches the end of the 
image i get a buffer with B_ERROR set and b_errno set to `invalid 
parameter' or `i/o error' depending to the mount of /dev/vnd0a or 
/dev/vnd0d.

When reading the image from the CD, i get a panic. This is due to the 
DIAGNOSTIC in vfs_bio.c:nestiobuf_done():1792 that checks if b_bufsize == 
b_bcount. It looks like dev/scsipi/cd.c adjusts the transfer size to not 
cross the border and when the read returns, its buffer's b_bcount is 
reflecting the number of bytes transfered. It is thus not equal to 
b_bufsize anymore and leads to the panic. Since it read in OK B_ERROR is 
clear and b_resid = 0.

What puzzles me is that vnd and cd both use bounds_check_with_label(). The 
only place in cd.c i found that changes b_bcount is when its marked as an 
ANCIENT disc. Since its an ATAPI it can never be marked that way.

The only other possible `vilan' to mess with the buffer is the channel 
adapter's minphys called in cdminphys(). Its a piixide adapter but i 
haven't found its adapt_minphys yet.

Any ideas? Should the KASSERT() in nestiobuf_iodone() be modified or should 
it detect this truncation of its transfer and flag an error?

thanks in advance,
Reinoud


--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ9D6EYKcNwBDyKpoAQI5hgf/UpypwiOYN/VMViMR7XG9oFNg1DtUdP7P
mA7AA73w7zdiJQsVKxhr4dVQpWSM9lG2U4ld9CKM1sbda5NwqN43jmJXLU0pSz8o
aLHyqRUe4R46b81B1Op62P+J9jRVTxZqD1pfN58SYE8YP2spY5y/lDNtCVsjAS+F
xQ+ecv0k2gKTNvFux8yX0G/xfX44EAE+vn0FWWDG6nNYN9BsYgavMxgcAX1UzV9k
xt+AK/py0H2IojwqR4fcZn7E6nUhsnBg+URcw9JaksAo8SlaP0k+rDEzGoUqCQDS
KNOK5V2eSwoK8D8UjVMSC4+X2fY9AxxaaVsO0xy/hEMSxJ+5IF8CyA==
=Dy98
-----END PGP SIGNATURE-----

--GvXjxJ+pjyke8COw--