[PATCH] Fix /proc/pid/pagemap return length calculation

[PATCH] Fix /proc/pid/pagemap return length calculation

[Dave Boutcher]

/proc/pid/pagemap has a header (usually 8 bytes) the length
of which needs to be compensated for when converting from
proc file offset to page number.  The calculation of the
starting page number (svpfn) compensates for this, but the
calculation of the ending page number (evpfn) does not, resulting
in reads returning 8 bytes more than were asked for and
nastily overwriting userspace memory.

Diffed against 2.6.23-rc1-mm2

Signed-off-by: Dave Boutcher <boutcher@cs.umn.edu>
---
 fs/proc/task_mmu.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 4594f15..b2baeab 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -627,7 +627,7 @@ static ssize_t pagemap_read(struct file *file, char __user *buf,
 	addr = PAGE_SIZE * svpfn;
 	if ((svpfn + 1) * sizeof(unsigned long) != src)
 		goto out;
-	evpfn = min((src + count) / sizeof(unsigned long),
+	evpfn = min((src + count) / sizeof(unsigned long) - 1,
 		    ((~0UL) >> PAGE_SHIFT) + 1);
 	count = (evpfn - svpfn) * sizeof(unsigned long);
 	end = PAGE_SIZE * evpfn;
-- 
1.4.4.2

Re: [PATCH] Fix /proc/pid/pagemap return length calculation

[Matt Mackall]

On Sun, Aug 05, 2007 at 09:03:23PM -0500, Dave Boutcher wrote:
> 
> /proc/pid/pagemap has a header (usually 8 bytes) the length
> of which needs to be compensated for when converting from
> proc file offset to page number.  The calculation of the
> starting page number (svpfn) compensates for this, but the
> calculation of the ending page number (evpfn) does not, resulting
> in reads returning 8 bytes more than were asked for and
> nastily overwriting userspace memory.

Does this mean you're running on a 64-bit arch? I'd already fixed this
locally, but it was off by 4 for me.

Acked-by: Matt Mackall <mpm@selenic.com>
 
> Diffed against 2.6.23-rc1-mm2
> 
> Signed-off-by: Dave Boutcher <boutcher@cs.umn.edu>
> ---
>  fs/proc/task_mmu.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 4594f15..b2baeab 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -627,7 +627,7 @@ static ssize_t pagemap_read(struct file *file, char __user *buf,
>  	addr = PAGE_SIZE * svpfn;
>  	if ((svpfn + 1) * sizeof(unsigned long) != src)
>  		goto out;
> -	evpfn = min((src + count) / sizeof(unsigned long),
> +	evpfn = min((src + count) / sizeof(unsigned long) - 1,
>  		    ((~0UL) >> PAGE_SHIFT) + 1);
>  	count = (evpfn - svpfn) * sizeof(unsigned long);
>  	end = PAGE_SIZE * evpfn;
> -- 
> 1.4.4.2

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] Fix /proc/pid/pagemap return length calculation

[Dave Boutcher]

On Sun, 5 Aug 2007 22:34:46 -0500, Matt Mackall <mpm@selenic.com> said:
> 
> On Sun, Aug 05, 2007 at 09:03:23PM -0500, Dave Boutcher wrote:
>> 
>> /proc/pid/pagemap has a header (usually 8 bytes) the length
>> of which needs to be compensated for when converting from
>> proc file offset to page number.  The calculation of the
>> starting page number (svpfn) compensates for this, but the
>> calculation of the ending page number (evpfn) does not, resulting
>> in reads returning 8 bytes more than were asked for and
>> nastily overwriting userspace memory.
> 
> Does this mean you're running on a 64-bit arch? I'd already fixed this
> locally, but it was off by 4 for me.
> 
> Acked-by: Matt Mackall <mpm@selenic.com>

Yeah, and there is going to be at least one more patch coming, since
with this fix, which is a righteous fix, things don't get copied up to
user space correctly since some other code was dependent on the borken 
length :-)

I like the /proc/xxx/pagemap function though...thanks for writing it.

Dave B