2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
for proc. Here is a patch.
BTW, ext2 2.4-test10 is ok.
--
H.J. Lu ([email protected])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.c Thu Nov 23 21:54:58 2000
@@ -120,6 +120,8 @@ static long long ext2_file_lseek(
case 1:
offset += file->f_pos;
}
+ if (offset < 0)
+ return -EINVAL;
if (((unsigned long long) offset >> 32) != 0) {
#if BITS_PER_LONG < 64
return -EINVAL;
--- linux/fs/proc/mem.c.lseek Tue Jan 4 10:12:23 2000
+++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000
@@ -196,14 +196,17 @@ static long long mem_lseek(struct file *
{
switch (orig) {
case 0:
- file->f_pos = offset;
- return file->f_pos;
+ break;
case 1:
- file->f_pos += offset;
- return file->f_pos;
+ offset += file->f_pos;
+ break;
default:
return -EINVAL;
}
+ if (offset < 0)
+ return -EINVAL;
+ file->f_pos = offset;
+ return offset;
}
/*
On Thu, Nov 23, 2000 at 10:15:24PM -0800, H . J . Lu wrote:
> 2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
> for proc. Here is a patch.
As just said your patch is wrong for vanilla 2.2.18pre23.
The right fix for that problem in 2.2.18pre23 (2.2.x vanilla doesn't include
LFS) is here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre22/lseek-2g-ext2-1
I also uploaded separately your right fix for /dev/mem:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre22/lseek-2g-mem-hjl-1 (this one is
and this the right fix for the largefile handling in ext2:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre22/notify-change-2g-ext2-1
All three should be applied to 2.2.18pre-latest.
And in LFS (that means also 2.4.x) the >> 32 doesn't make any sense in lseek
and should be removed:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test11-pre6/ext2-lseek-cleanup-1
Andrea
On Fri, 24 Nov 2000, Andrea Arcangeli wrote:
> And in LFS (that means also 2.4.x) the >> 32 doesn't make any sense in lseek
> and should be removed:
Actually, the >> 32 part was there to avoid doing the long long comparison
on x86. Granted, that probably doesn't matter.
-ben