| Submitter | Darrick J. Wong |
|---|---|
| Date | Sept. 15, 2011, 11:16 p.m. |
| Message ID | <20110915231645.GE12086@tux1.beaverton.ibm.com> |
| Download | mbox | patch |
| Permalink | /patch/114869/ |
| State | Superseded |
| Headers | show |
Comments
"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
Patch
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); } }
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(-) -- 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