Hi,
I've been running the following patch (which uses discreet
tests vs a common temp off_t variable). Would someone please
consider committing either this patch or the one given in
the pr? It doesn't really matter to me, but I would like to
see this bug put to rest.
Comments welcome!
Thanks,
John
ps: The following patch differs from the one given in the pr for
the simple reason that I don't like making assumptions about
overflow handling during math operations. In the patch below,
L_XTND nolonger depends on overflow assumptions, but L_INCR
still does. L_INCR really needs to be something like:
if ((MAXFILESIZE - fp->f_offset) < SCARG(uap, offset))
return (EINVAL);
but, I am not aware of a MAXFILESIZE definition unless I
try to construct one using operations based on the sizeof()
an off_t. Comments?
patch by [EMAIL PROTECTED]
Index: vfs_syscalls.c
===================================================================
RCS file: /mirror/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.135
diff -u -r1.135 vfs_syscalls.c
--- vfs_syscalls.c 1999/09/11 00:45:58 1.135
+++ vfs_syscalls.c 1999/09/19 02:48:59
@@ -1433,15 +1433,22 @@
return (ESPIPE);
switch (SCARG(uap, whence)) {
case L_INCR:
+ if ((fp->f_offset + SCARG(uap, offset)) < 0)
+ return (EINVAL);
fp->f_offset += SCARG(uap, offset);
break;
case L_XTND:
error=VOP_GETATTR((struct vnode *)fp->f_data, &vattr, cred, p);
if (error)
return (error);
+ if ((SCARG(uap, offset) < 0) &&
+ ((-SCARG(uap, offset)) > vattr.va_size))
+ return (EINVAL);
fp->f_offset = SCARG(uap, offset) + vattr.va_size;
break;
case L_SET:
+ if (SCARG(uap, offset) < 0)
+ return (EINVAL);
fp->f_offset = SCARG(uap, offset);
break;
default:
> On Tue, Aug 24, 1999 at 04:25:26PM -0400, John W. DeBoskey wrote:
>
> > The subject says it all... We have some code that scans files
> > backwards...
> >
> > In looking through /usr/src/sys/kern/vfs_syscalls.c I can't see
> > where we do any validation on the resulting seek location... Do the
> > appropriate folks think this is a bug? How about posix? Should I
> > go ahead and submit a pr with a patch?
>
> I've just discovered kern/6184 (from Mar 1998, state: open). Seems like
> patch which fixes it was never commited.
>
> V.
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
