Calling the driver-specific ioctl first, then bailing because
CAP_SYS_ADMIN is not set, can lead to an inconsistency between the
driver and the block layer, where one thinks the device is read only,
and the other considers it readwrite.
Fix this by checking the capability first, like the rest of the block
ioctls that require it. This bug was introduced pre-git in commit
23deaf89e3075b9271c7f48a2764ae3ed8f9573a.
Signed-off-by: Josh Durgin <josh.dur...@inktank.com>
---
block/ioctl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index a31d91d..6e5933e 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -293,11 +293,11 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode,
unsigned cmd,
return 0;
case BLKROSET:
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
if (!is_unrecognized_ioctl(ret))
return ret;
- if (!capable(CAP_SYS_ADMIN))
- return -EACCES;
if (get_user(n, (int __user *)(arg)))
return -EFAULT;
set_device_ro(bdev, n);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
