[PATCH] ext4: Prevent stack overrun in ext4_file_open when recording last known mountpoint

[PATCH] ext4: Prevent stack overrun in ext4_file_open when recording last known mountpoint

[Darrick J. Wong]

In ext4_file_open, the filesystem records the mountpoint of the first file that
is opened after mounting the filesystem.  It does this by allocating a 64-byte
stack buffer, calling d_path() to grab the mount point through which this file
was accessed, and then memcpy()ing 64 bytes into the superblock's
s_last_mounted field, starting from the return value of d_path(), which is
stored as "cp".  However, if cp > buf (which it frequently is since path
components are prepended starting at the end of buf) then we can end up copying
stack data into the superblock.

Writing stack variables into the superblock doesn't sound like a great idea, so
use strncpy instead.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
---

 fs/ext4/file.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index e4095e9..67223e0 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -181,8 +181,8 @@ static int ext4_file_open(struct inode * inode, struct file * filp)
 		path.dentry = mnt->mnt_root;
 		cp = d_path(&path, buf, sizeof(buf));
 		if (!IS_ERR(cp)) {
-			memcpy(sbi->s_es->s_last_mounted, cp,
-			       sizeof(sbi->s_es->s_last_mounted));
+			strncpy(sbi->s_es->s_last_mounted, cp,
+				sizeof(sbi->s_es->s_last_mounted));
 			ext4_mark_super_dirty(sb);
 		}
 	}

Re: [PATCH] ext4: Prevent stack overrun in ext4_file_open when recording last known mountpoint

[Andi Kleen]

"Darrick J. Wong" <djwong@us.ibm.com> writes:


> Writing stack variables into the superblock doesn't sound like a great idea, so
> use strncpy instead.

This means you can end up with a non 0 terminated path in the
superblock, which could confuse programs.

Better use strlcpy()

strncpy is usually a bad idea, it's semantics overall are quite
bogus and it's also inefficient because it always fills.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

[PATCH v2] ext4: Prevent stack overrun in ext4_file_open when recording last known mountpoint

[Darrick J. Wong]

In ext4_file_open, the filesystem records the mountpoint of the first file that
is opened after mounting the filesystem.  It does this by allocating a 64-byte
stack buffer, calling d_path() to grab the mount point through which this file
was accessed, and then memcpy()ing 64 bytes into the superblock's
s_last_mounted field, starting from the return value of d_path(), which is
stored as "cp".  However, if cp > buf (which it frequently is since path
components are prepended starting at the end of buf) then we can end up copying
stack data into the superblock.

Writing stack variables into the superblock doesn't sound like a great idea, so
use strlcpy instead.  Andi Kleen suggested using strlcpy instead of strncpy.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
---

 fs/ext4/file.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index e4095e9..9781099 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -181,8 +181,8 @@ static int ext4_file_open(struct inode * inode, struct file * filp)
 		path.dentry = mnt->mnt_root;
 		cp = d_path(&path, buf, sizeof(buf));
 		if (!IS_ERR(cp)) {
-			memcpy(sbi->s_es->s_last_mounted, cp,
-			       sizeof(sbi->s_es->s_last_mounted));
+			strlcpy(sbi->s_es->s_last_mounted, cp,
+				sizeof(sbi->s_es->s_last_mounted));
 			ext4_mark_super_dirty(sb);
 		}
 	}

Re: [PATCH v2] ext4: Prevent stack overrun in ext4_file_open when recording last known mountpoint

[Darrick J. Wong]

On Fri, Sep 16, 2011 at 11:40:05AM -0700, Darrick J. Wong wrote:
> In ext4_file_open, the filesystem records the mountpoint of the first file that
> is opened after mounting the filesystem.  It does this by allocating a 64-byte
> stack buffer, calling d_path() to grab the mount point through which this file
> was accessed, and then memcpy()ing 64 bytes into the superblock's
> s_last_mounted field, starting from the return value of d_path(), which is
> stored as "cp".  However, if cp > buf (which it frequently is since path
> components are prepended starting at the end of buf) then we can end up copying
> stack data into the superblock.
> 
> Writing stack variables into the superblock doesn't sound like a great idea, so
> use strlcpy instead.  Andi Kleen suggested using strlcpy instead of strncpy.

Ok, it's been a couple of weeks.... any thoughts, Ted?

--D
> 
> Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
> ---
> 
>  fs/ext4/file.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> index e4095e9..9781099 100644
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@ -181,8 +181,8 @@ static int ext4_file_open(struct inode * inode, struct file * filp)
>  		path.dentry = mnt->mnt_root;
>  		cp = d_path(&path, buf, sizeof(buf));
>  		if (!IS_ERR(cp)) {
> -			memcpy(sbi->s_es->s_last_mounted, cp,
> -			       sizeof(sbi->s_es->s_last_mounted));
> +			strlcpy(sbi->s_es->s_last_mounted, cp,
> +				sizeof(sbi->s_es->s_last_mounted));
>  			ext4_mark_super_dirty(sb);
>  		}
>  	}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v2] ext4: Prevent stack overrun in ext4_file_open when recording last known mountpoint

[Lukas Czerner]

On Fri, 30 Sep 2011, Darrick J. Wong wrote:

> On Fri, Sep 16, 2011 at 11:40:05AM -0700, Darrick J. Wong wrote:
> > In ext4_file_open, the filesystem records the mountpoint of the first file that
> > is opened after mounting the filesystem.  It does this by allocating a 64-byte
> > stack buffer, calling d_path() to grab the mount point through which this file
> > was accessed, and then memcpy()ing 64 bytes into the superblock's
> > s_last_mounted field, starting from the return value of d_path(), which is
> > stored as "cp".  However, if cp > buf (which it frequently is since path
> > components are prepended starting at the end of buf) then we can end up copying
> > stack data into the superblock.
> > 
> > Writing stack variables into the superblock doesn't sound like a great idea, so
> > use strlcpy instead.  Andi Kleen suggested using strlcpy instead of strncpy.
> 
> Ok, it's been a couple of weeks.... any thoughts, Ted?
> 
> --D

Makes sense.

Reviewed-by: Lukas Czerner <lczerner@redhat.com>

> > 
> > Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
> > ---
> > 
> >  fs/ext4/file.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> > index e4095e9..9781099 100644
> > --- a/fs/ext4/file.c
> > +++ b/fs/ext4/file.c
> > @@ -181,8 +181,8 @@ static int ext4_file_open(struct inode * inode, struct file * filp)
> >  		path.dentry = mnt->mnt_root;
> >  		cp = d_path(&path, buf, sizeof(buf));
> >  		if (!IS_ERR(cp)) {
> > -			memcpy(sbi->s_es->s_last_mounted, cp,
> > -			       sizeof(sbi->s_es->s_last_mounted));
> > +			strlcpy(sbi->s_es->s_last_mounted, cp,
> > +				sizeof(sbi->s_es->s_last_mounted));
> >  			ext4_mark_super_dirty(sb);
> >  		}
> >  	}
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>