| Message ID | 20170423174653.GO23371@birch.djwong.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index eee8b0f..6190697 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -1674,7 +1674,7 @@ xfs_ioc_getfsmap( return error; /* If we didn't abort, set the "last" flag in the last fmx */ - if (!aborted && xhead.fmh_entries) { + if (!aborted && info.idx) { info.last_flags |= FMR_OF_LAST; if (copy_to_user(&info.data->fmh_recs[info.idx - 1].fmr_flags, &info.last_flags, sizeof(info.last_flags)))
At the end of a getfsmap call, we will set FMR_OF_LAST in the last struct fsmap that was handed in by userspace if we've truly run out of space mapping record (as opposed to simply running out of space in the user array). Unfortunately, fmh_entries is the wrong check for whether or not we've filled out anything in the user array because the ioctl provides that fmh_count==0 sets fmh_entries without filling out the fsmap array. Therefore we end up writing things into user memory areas that we weren't given, and kaboom. Since Christoph amended the getfsmap structure to track the number of fsmap entries we've actually filled out, use that as part of deciding if we have to set the OF_LAST flag. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> --- fs/xfs/xfs_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html