From: syzbot <syzbot+660d079d90f8a1baf54d@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] block: add allocation size check in blkdev_pr_read_keys()
Date: Mon, 15 Dec 2025 20:39:57 -0800 [thread overview]
Message-ID: <6940e29d.a70a0220.33cd7b.0132.GAE@google.com> (raw)
In-Reply-To: <693b4abb.a70a0220.33cd7b.003a.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] block: add allocation size check in blkdev_pr_read_keys()
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
blkdev_pr_read_keys() takes num_keys from userspace and uses it to
calculate the allocation size for keys_info via struct_size(). While
there is a check for SIZE_MAX (integer overflow), there is no upper
bound validation on the allocation size itself.
A malicious or buggy userspace can pass a large num_keys value that
doesn't trigger overflow but still results in an excessive allocation
attempt, causing a warning in the page allocator when the order exceeds
MAX_PAGE_ORDER.
Fix this by introducing PR_KEYS_MAX_NUM to limit the number of keys to
a sane value. This makes the SIZE_MAX check redundant, so remove it.
Also switch to kvzalloc/kvfree to handle larger allocations gracefully.
Fixes: 22a1ffea5f80 ("block: add IOC_PR_READ_KEYS ioctl")
Reported-by: syzbot+660d079d90f8a1baf54d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=660d079d90f8a1baf54d
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v2:
- Added PR_KEYS_MAX_NUM (64K) limit instead of checking KMALLOC_MAX_SIZE
- Removed redundant SIZE_MAX check
- Switched to kvzalloc/kvfree
---
block/ioctl.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index 61feed686418..98c4c7b9e7fe 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -18,6 +18,8 @@
#include "blk.h"
#include "blk-crypto-internal.h"
+#define PR_KEYS_MAX_NUM (1u << 16)
+
static int blkpg_do_ioctl(struct block_device *bdev,
struct blkpg_partition __user *upart, int op)
{
@@ -442,11 +444,12 @@ static int blkdev_pr_read_keys(struct block_device *bdev, blk_mode_t mode,
if (copy_from_user(&read_keys, arg, sizeof(read_keys)))
return -EFAULT;
- keys_info_len = struct_size(keys_info, keys, read_keys.num_keys);
- if (keys_info_len == SIZE_MAX)
+ if (read_keys.num_keys > PR_KEYS_MAX_NUM)
return -EINVAL;
- keys_info = kzalloc(keys_info_len, GFP_KERNEL);
+ keys_info_len = struct_size(keys_info, keys, read_keys.num_keys);
+
+ keys_info = kvzalloc(keys_info_len, GFP_KERNEL);
if (!keys_info)
return -ENOMEM;
@@ -473,7 +476,7 @@ static int blkdev_pr_read_keys(struct block_device *bdev, blk_mode_t mode,
if (copy_to_user(arg, &read_keys, sizeof(read_keys)))
ret = -EFAULT;
out:
- kfree(keys_info);
+ kvfree(keys_info);
return ret;
}
--
2.43.0
prev parent reply other threads:[~2025-12-16 4:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 22:50 [syzbot] [mm?] WARNING in blkdev_common_ioctl syzbot
2025-12-12 1:03 ` Forwarded: [PATCH] block: add allocation size check in blkdev_pr_read_keys() syzbot
2025-12-16 4:39 ` syzbot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6940e29d.a70a0220.33cd7b.0132.GAE@google.com \
--to=syzbot+660d079d90f8a1baf54d@syzkaller.appspotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.