Date: Mon, 23 Aug 1999 02:21:56 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, phk@critter.freebsd.dk Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, green@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_physio.c Message-ID: <199908221621.CAA30375@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>btodb() probably shouldn't cast to daddr_t. This mainly prevents its >>use in code like the above. It is not a feature that it may prevent >>warnings about truncation when off_t's are assigned to daddr_t's. > >btodb() probably shouldn't be used for off_t... It seems to be used mostly to convert fs block sizes to "disk blocks". The places that use it for off_t's seem to mostly have the same bug that you fixed. There's one in vfs_aio.c, one in vinumio.c, and 3 in each of spec_vnops.c and devfs_vnops.c. Only he ones for getpages in the last to files have a bounds check, and it is verbose and broken (I forgot the sign bit in daddr_t and have been sitting on the fix for a year or 2) :-(. It is used with a long arg in a few places. Longs are the same as off_t's on alphas, so overflows can't be ruled out by compile-time checking. There don't seem to be enough checks for uio_offset < 0. Negative offsets may be set by lseek(), and I think they normally get passed to quite low level routines. ffs_read() handles them dubiously by interpreting them as large unsigned offsets and returning EFBIG. POSIX.1 seems to require disallowing bogus seeks so that read() and write() don't have to worry about bogus offsets (there is no documented error return for attempts to read from bogus offsets in POSIX. FreeBSD's read.2 documents EINVAL for attempts to read from negative offsets, but negative offsets may be non-bogus for some files, e.g., /dev/mem on a 64-bit system). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908221621.CAA30375>