# \[PATCH\] vfs: cap dedupe request structure size at PAGE\_SIZE

- Subsystems: FILESYSTEMS (VFS and infrastructure), LANDLOCK SECURITY MODULE, THE REST
- Maintainers: Alexander Viro, Christian Brauner, Mickaël Salaün, Linus Torvalds
- List: linux-api
- 3 messages, 3 authors
- Page: https://ratatoskr.run/linux-api/2016/07/109679/t

## \[PATCH\] vfs: cap dedupe request structure size at PAGE\_SIZE

- From: Darrick J. Wong \<hidden\>
- Date: 2016-07-28 18:35:45 
- Message: https://ratatoskr.run/linux-api/2016/07/109679.md

```text
Kirill A. Shutemov reports that the kernel doesn't try to cap dest_count
in any way, and uses the number to allocate kernel memory.  This causes
high order allocation warnings in the kernel log if someone passes in a
big enough value.  We should clamp the allocation at PAGE_SIZE to avoid
stressing the VM.

The two existing users of the dedupe ioctl never send more than 120
requests, so we can safely clamp dest_range at PAGE_SIZE, because with
4k pages we can handle up to 127 dedupe candidates.  Given the max
extent length of 16MB, we can end up doing 2GB of IO which is plenty.

Reported-by: "Kirill A. Shutemov" <redacted>
Signed-off-by: Darrick J. Wong <redacted>
---
 fs/ioctl.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/ioctl.c b/fs/ioctl.c
index db3d033..57409a7 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -582,6 +582,10 @@ static int ioctl_file_dedupe_range(struct file *file, void __user *arg)
 	}
 
 	size = offsetof(struct file_dedupe_range __user, info[count]);
+	if (size > PAGE_SIZE) {
+		ret = -ENOMEM;
+		goto out;
+	}
 
 	same = memdup_user(argp, size);
 	if (IS_ERR(same)) {
```

## Re: \[PATCH\] vfs: cap dedupe request structure size at PAGE\_SIZE

- From: Christoph Hellwig \<hch@infradead.org\>
- Date: 2016-08-01 06:31:31 
- Message: https://ratatoskr.run/linux-api/2016/08/110710.md

```text
On Thu, Jul 28, 2016 at 11:35:34AM -0700, Darrick J. Wong wrote:
> Kirill A. Shutemov reports that the kernel doesn't try to cap dest_count
> in any way, and uses the number to allocate kernel memory.  This causes
> high order allocation warnings in the kernel log if someone passes in a
> big enough value.  We should clamp the allocation at PAGE_SIZE to avoid
> stressing the VM.
> 
> The two existing users of the dedupe ioctl never send more than 120
> requests, so we can safely clamp dest_range at PAGE_SIZE, because with
> 4k pages we can handle up to 127 dedupe candidates.  Given the max
> extent length of 16MB, we can end up doing 2GB of IO which is plenty.

Looks fine,

Reviewed-by: Christoph Hellwig <redacted>

> @@ -582,6 +582,10 @@ static int ioctl_file_dedupe_range(struct file *file, void __user *arg)

This function returns long in mainline.  Maybe you should resend your
return type fix to Al while you're at it?
```

## Re: \[PATCH\] vfs: cap dedupe request structure size at PAGE\_SIZE

- From: Mark Fasheh \<hidden\>
- Date: 2016-08-02 05:35:17 
- Message: https://ratatoskr.run/linux-api/2016/08/111171.md

```text
On Thu, Jul 28, 2016 at 11:35:34AM -0700, Darrick J. Wong wrote:
> Kirill A. Shutemov reports that the kernel doesn't try to cap dest_count
> in any way, and uses the number to allocate kernel memory.  This causes
> high order allocation warnings in the kernel log if someone passes in a
> big enough value.  We should clamp the allocation at PAGE_SIZE to avoid
> stressing the VM.
> 
> The two existing users of the dedupe ioctl never send more than 120
> requests, so we can safely clamp dest_range at PAGE_SIZE, because with
> 4k pages we can handle up to 127 dedupe candidates.  Given the max
> extent length of 16MB, we can end up doing 2GB of IO which is plenty.
> 
> Reported-by: "Kirill A. Shutemov" <redacted>
> Signed-off-by: Darrick J. Wong <redacted>

Reviewed-by: Mark Fasheh <redacted>

--
Mark Fasheh

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
```