[syzbot] [mm?] WARNING in blkdev_common_ioctl

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: cb015814f8b6 Merge tag 'f2fs-for-6.19-rc1' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17215992580000
kernel config: https://syzkaller.appspot.com/x/.config?x=4ba13acbacc6118f
dashboard link: https://syzkaller.appspot.com/bug?extid=660d079d90f8a1baf54d
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d49a1a580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=100e2a1a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/fe039b381b1b/disk-cb015814.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/499efdc87215/vmlinux-cb015814.xz
kernel image: https://storage.googleapis.com/syzbot-assets/515c65eb7e89/bzImage-cb015814.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+660d07...@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: mm/page_alloc.c:5186 at __alloc_frozen_pages_noprof+0x309/0x2430 mm/page_alloc.c:5186, CPU#1: syz.0.17/6010
Modules linked in:
CPU: 1 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:__alloc_frozen_pages_noprof+0x309/0x2430 mm/page_alloc.c:5186
Code: f0 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d1 42 5e 09 83 fe 0a 0f 86 0c fe ff ff 80 3d 84 7b 57 0e 00 75 0b c6 05 7b 7b 57 0e 01 90 <0f> 0b 90 45 31 f6 eb 81 4d 85 f6 74 22 44 89 fa 89 ee 4c 89 f7 e8
RSP: 0018:ffffc9000414f888 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000017 RDI: 0000000000040dc0
RBP: 0000000000000017 R08: 0000000000000005 R09: 0000000000000009
R10: 0000000000000017 R11: ffff88802ffe4830 R12: 0000000000040dc0
R13: 1ffff92000829f27 R14: ffffffff9ac29ac4 R15: 0000000000000017
FS: 0000555575978500(0000) GS:ffff888124a0e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000240 CR3: 000000007b864000 CR4: 00000000003526f0
Call Trace:
<TASK>
alloc_pages_mpol+0x1fb/0x550 mm/mempolicy.c:2486
___kmalloc_large_node+0x10c/0x150 mm/slub.c:5593
__kmalloc_large_node_noprof+0x1c/0x70 mm/slub.c:5624
__do_kmalloc_node mm/slub.c:5640 [inline]
__kmalloc_noprof.cold+0xc/0x62 mm/slub.c:5664
kmalloc_noprof include/linux/slab.h:961 [inline]
kzalloc_noprof include/linux/slab.h:1094 [inline]
blkdev_pr_read_keys block/ioctl.c:449 [inline]
blkdev_common_ioctl+0x1f72/0x2b60 block/ioctl.c:729
blkdev_ioctl+0x2b5/0x6e0 block/ioctl.c:785
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f6c89d8f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fffde61cdd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f6c89fe5fa0 RCX: 00007f6c89d8f7c9
RDX: 0000000000000000 RSI: 00000000c01070ce RDI: 0000000000000003
RBP: 00007f6c89e13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f6c89fe5fa0 R14: 00007f6c89fe5fa0 R15: 0000000000000003
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] block: add allocation size check in blkdev_pr_read_keys()
Author: karti...@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 checking that keys_info_len does not exceed KMALLOC_MAX_SIZE
before attempting the allocation.

Reported-by: syzbot+660d07...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=660d079d90f8a1baf54d
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
block/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index 61feed686418..3e9e4257569f 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -443,7 +443,7 @@ static int blkdev_pr_read_keys(struct block_device *bdev, blk_mode_t mode,
return -EFAULT;

keys_info_len = struct_size(keys_info, keys, read_keys.num_keys);
- if (keys_info_len == SIZE_MAX)
+ if (keys_info_len == SIZE_MAX || keys_info_len > KMALLOC_MAX_SIZE)
return -EINVAL;

keys_info = kzalloc(keys_info_len, GFP_KERNEL);
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+660d07...@syzkaller.appspotmail.com
Tested-by: syzbot+660d07...@syzkaller.appspotmail.com

Tested on:

commit: d358e525 Merge tag 'for-6.19/dm-changes' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14359592580000
kernel config: https://syzkaller.appspot.com/x/.config?x=37bf6cac94c6b2f8

dashboard link: https://syzkaller.appspot.com/bug?extid=660d079d90f8a1baf54d
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40

patch: https://syzkaller.appspot.com/x/patch.diff?x=14a5a61a580000

Note: testing is done by a robot and is best-effort only.

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] block: add allocation size check in blkdev_pr_read_keys()
Author: karti...@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+660d07...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=660d079d90f8a1baf54d
Signed-off-by: Deepanshu Kartikey <karti...@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

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+660d07...@syzkaller.appspotmail.com
Tested-by: syzbot+660d07...@syzkaller.appspotmail.com

Tested on:

commit: 8f0b4cce Linux 6.19-rc1
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17c47f08580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8bfa57a8c0ab3aa8

dashboard link: https://syzkaller.appspot.com/bug?extid=660d079d90f8a1baf54d
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40

patch: https://syzkaller.appspot.com/x/patch.diff?x=1372711a580000