| Message ID | b95aca069607600ffd1efc95803cf39c13768b4d.1588222212.git.riteshh@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | [PATCHv3,1/1] fibmap: Warn and return an error in case of block > INT_MAX | expand |
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
On Thu 30-04-20 10:25:18, Ritesh Harjani wrote: > We better warn the fibmap user and not return a truncated and therefore > an incorrect block map address if the bmap() returned block address > is greater than INT_MAX (since user supplied integer pointer). > > It's better to pr_warn() all user of ioctl_fibmap() and return a proper > error code rather than silently letting a FS corruption happen if the > user tries to fiddle around with the returned block map address. > > We fix this by returning an error code of -ERANGE and returning 0 as the > block mapping address in case if it is > INT_MAX. > > Now iomap_bmap() could be called from either of these two paths. > Either when a user is calling an ioctl_fibmap() interface to get > the block mapping address or by some filesystem via use of bmap() > internal kernel API. > bmap() kernel API is well equipped with handling of u64 addresses. > > WARN condition in iomap_bmap_actor() was mainly added to warn all > the fibmap users. But now that we have directly added this warning > for all fibmap users and also made sure to return 0 as block map address > in case if addr > INT_MAX. > So we can now remove this logic from iomap_bmap_actor(). > > Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Looks good to me. You can add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > --- > v2 -> v3: > 1. Added file path info using (%pD4) > 2. Dropped Reviewed-by tags for reviewing this final version. > > fs/ioctl.c | 8 ++++++++ > fs/iomap/fiemap.c | 5 +---- > 2 files changed, 9 insertions(+), 4 deletions(-) > > diff --git a/fs/ioctl.c b/fs/ioctl.c > index f1d93263186c..6b8629fbe0fd 100644 > --- a/fs/ioctl.c > +++ b/fs/ioctl.c > @@ -55,6 +55,7 @@ EXPORT_SYMBOL(vfs_ioctl); > static int ioctl_fibmap(struct file *filp, int __user *p) > { > struct inode *inode = file_inode(filp); > + struct super_block *sb = inode->i_sb; > int error, ur_block; > sector_t block; > > @@ -71,6 +72,13 @@ static int ioctl_fibmap(struct file *filp, int __user *p) > block = ur_block; > error = bmap(inode, &block); > > + if (block > INT_MAX) { > + error = -ERANGE; > + pr_warn_ratelimited("[%s/%d] FS: %s File: %pD4 would truncate fibmap result\n", > + current->comm, task_pid_nr(current), > + sb->s_id, filp); > + } > + > if (error) > ur_block = 0; > else > diff --git a/fs/iomap/fiemap.c b/fs/iomap/fiemap.c > index bccf305ea9ce..d55e8f491a5e 100644 > --- a/fs/iomap/fiemap.c > +++ b/fs/iomap/fiemap.c > @@ -117,10 +117,7 @@ iomap_bmap_actor(struct inode *inode, loff_t pos, loff_t length, > > if (iomap->type == IOMAP_MAPPED) { > addr = (pos - iomap->offset + iomap->addr) >> inode->i_blkbits; > - if (addr > INT_MAX) > - WARN(1, "would truncate bmap result\n"); > - else > - *bno = addr; > + *bno = addr; > } > return 0; > } > -- > 2.21.0 >
On Thu, Apr 30, 2020 at 10:25:18AM +0530, Ritesh Harjani wrote: > We better warn the fibmap user and not return a truncated and therefore > an incorrect block map address if the bmap() returned block address > is greater than INT_MAX (since user supplied integer pointer). > > It's better to pr_warn() all user of ioctl_fibmap() and return a proper > error code rather than silently letting a FS corruption happen if the > user tries to fiddle around with the returned block map address. > > We fix this by returning an error code of -ERANGE and returning 0 as the > block mapping address in case if it is > INT_MAX. > > Now iomap_bmap() could be called from either of these two paths. > Either when a user is calling an ioctl_fibmap() interface to get > the block mapping address or by some filesystem via use of bmap() > internal kernel API. > bmap() kernel API is well equipped with handling of u64 addresses. > > WARN condition in iomap_bmap_actor() was mainly added to warn all > the fibmap users. But now that we have directly added this warning > for all fibmap users and also made sure to return 0 as block map address > in case if addr > INT_MAX. > So we can now remove this logic from iomap_bmap_actor(). > > Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Looks good to me, Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> --D > --- > v2 -> v3: > 1. Added file path info using (%pD4) > 2. Dropped Reviewed-by tags for reviewing this final version. > > fs/ioctl.c | 8 ++++++++ > fs/iomap/fiemap.c | 5 +---- > 2 files changed, 9 insertions(+), 4 deletions(-) > > diff --git a/fs/ioctl.c b/fs/ioctl.c > index f1d93263186c..6b8629fbe0fd 100644 > --- a/fs/ioctl.c > +++ b/fs/ioctl.c > @@ -55,6 +55,7 @@ EXPORT_SYMBOL(vfs_ioctl); > static int ioctl_fibmap(struct file *filp, int __user *p) > { > struct inode *inode = file_inode(filp); > + struct super_block *sb = inode->i_sb; > int error, ur_block; > sector_t block; > > @@ -71,6 +72,13 @@ static int ioctl_fibmap(struct file *filp, int __user *p) > block = ur_block; > error = bmap(inode, &block); > > + if (block > INT_MAX) { > + error = -ERANGE; > + pr_warn_ratelimited("[%s/%d] FS: %s File: %pD4 would truncate fibmap result\n", > + current->comm, task_pid_nr(current), > + sb->s_id, filp); > + } > + > if (error) > ur_block = 0; > else > diff --git a/fs/iomap/fiemap.c b/fs/iomap/fiemap.c > index bccf305ea9ce..d55e8f491a5e 100644 > --- a/fs/iomap/fiemap.c > +++ b/fs/iomap/fiemap.c > @@ -117,10 +117,7 @@ iomap_bmap_actor(struct inode *inode, loff_t pos, loff_t length, > > if (iomap->type == IOMAP_MAPPED) { > addr = (pos - iomap->offset + iomap->addr) >> inode->i_blkbits; > - if (addr > INT_MAX) > - WARN(1, "would truncate bmap result\n"); > - else > - *bno = addr; > + *bno = addr; > } > return 0; > } > -- > 2.21.0 >
diff --git a/fs/ioctl.c b/fs/ioctl.c index f1d93263186c..6b8629fbe0fd 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -55,6 +55,7 @@ EXPORT_SYMBOL(vfs_ioctl); static int ioctl_fibmap(struct file *filp, int __user *p) { struct inode *inode = file_inode(filp); + struct super_block *sb = inode->i_sb; int error, ur_block; sector_t block; @@ -71,6 +72,13 @@ static int ioctl_fibmap(struct file *filp, int __user *p) block = ur_block; error = bmap(inode, &block); + if (block > INT_MAX) { + error = -ERANGE; + pr_warn_ratelimited("[%s/%d] FS: %s File: %pD4 would truncate fibmap result\n", + current->comm, task_pid_nr(current), + sb->s_id, filp); + } + if (error) ur_block = 0; else diff --git a/fs/iomap/fiemap.c b/fs/iomap/fiemap.c index bccf305ea9ce..d55e8f491a5e 100644 --- a/fs/iomap/fiemap.c +++ b/fs/iomap/fiemap.c @@ -117,10 +117,7 @@ iomap_bmap_actor(struct inode *inode, loff_t pos, loff_t length, if (iomap->type == IOMAP_MAPPED) { addr = (pos - iomap->offset + iomap->addr) >> inode->i_blkbits; - if (addr > INT_MAX) - WARN(1, "would truncate bmap result\n"); - else - *bno = addr; + *bno = addr; } return 0; }
We better warn the fibmap user and not return a truncated and therefore an incorrect block map address if the bmap() returned block address is greater than INT_MAX (since user supplied integer pointer). It's better to pr_warn() all user of ioctl_fibmap() and return a proper error code rather than silently letting a FS corruption happen if the user tries to fiddle around with the returned block map address. We fix this by returning an error code of -ERANGE and returning 0 as the block mapping address in case if it is > INT_MAX. Now iomap_bmap() could be called from either of these two paths. Either when a user is calling an ioctl_fibmap() interface to get the block mapping address or by some filesystem via use of bmap() internal kernel API. bmap() kernel API is well equipped with handling of u64 addresses. WARN condition in iomap_bmap_actor() was mainly added to warn all the fibmap users. But now that we have directly added this warning for all fibmap users and also made sure to return 0 as block map address in case if addr > INT_MAX. So we can now remove this logic from iomap_bmap_actor(). Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> --- v2 -> v3: 1. Added file path info using (%pD4) 2. Dropped Reviewed-by tags for reviewing this final version. fs/ioctl.c | 8 ++++++++ fs/iomap/fiemap.c | 5 +---- 2 files changed, 9 insertions(+), 4 deletions(-)