From nobody Sat Feb 7 20:44:07 2026 Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FEC1274B58 for ; Tue, 16 Dec 2025 04:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.70 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765860006; cv=none; b=Wzz/LcFtk8kI0olIqAwTNooyr/PTXEzQwdQKJ2aRreHtgvCfQyrDlUCWcEUmQQCu9G/cgNCn+eoA9epCo2NwhDOz3cGbV8QaXVw3l4Bsf1E137zIygLF/bShbvwEESNnQ0FRvhcoJ73a9UMA03RU+RxKCVYV/f6ZoRbMtRiGchc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765860006; c=relaxed/simple; bh=u5s2b0LnLHlWK8SZL5nVCNQLG/YuvGvA1rIpawygirA=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=sJ1Xg4M2sMk34taFuArW+wWHYWVSKQFGnN5d/qNcm+LxLiq8epH8NtCkNesQd3OgRkHEfrtaMoRZX1ZQTJY0pNGkToDYjrrladDhSLZpLKxelQOVLi2mlq28cNvFBCktggXurYWUgdCXWiObLauRrtsAMzQiMUY6sk2KOzTsPIs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-657486eb435so6055785eaf.1 for ; Mon, 15 Dec 2025 20:39:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765859997; x=1766464797; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7cj/y9XacHHtuTy9g1x71cGjEtgV6hiIh/UuePOdT7A=; b=cAtXJdJbcvd8z0QW0hezEHeNkV8xhhW9zERWRuLmpzA37DVhpPTaY+pCqosNqU6zgc 6cKtx3VJAlVt0GIbeaRksF7ZchMTGp3ijb3ZsspV45IFXepkXjKHhwyiR7xBNQD72XlL NaSjlNVivGX+MKKa6VN9TYx5w/vU+2fhTydiS4ctbSahXWfwOVb3f87aRDXnsA8dTKIH Eb+f0u+wdXhKYhRioBZMCWmfskNO0d+NaKBROC78lxkTw6nfQtIRC2UukSwR/yn3r/MP hSwZaS9YWaG7DkXAeTI9csytQm2aMsRvPewvAnZz0TIfQ6rPhuLzUex0GjFF+KrNBYWc SFrg== X-Gm-Message-State: AOJu0Yxm1i4yNqUTRXhnZoxhp7Ffe4WVFt979+pkVclxaZ/1+8ZFwEBW +vpHnatWUij4jWSc+BmtvnVLxUBRj+K9dccus4+LypVll3Tu+dtatZSph1gjH2r3hfNP2ZkzVqW rjrJMoJ5Gvo28QqJ905hIGONplcLMPX4n2C4jvrJkMsAJ5c92iEW864kALUk= X-Google-Smtp-Source: AGHT+IEVKwsjqf0pY11YPwoNgljSw/7INc7mEUGscFNqKvAYV9z0imtjNQS9HZOODOfx98j8LALMNmmkxWq0Vj8I0YM2oxJf3VeJ Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:1b13:b0:65b:2511:a7d3 with SMTP id 006d021491bc7-65b45200bddmr5900510eaf.49.1765859997195; Mon, 15 Dec 2025 20:39:57 -0800 (PST) Date: Mon, 15 Dec 2025 20:39:57 -0800 In-Reply-To: <693b4abb.a70a0220.33cd7b.003a.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <6940e29d.a70a0220.33cd7b.0132.GAE@google.com> Subject: Forwarded: [PATCH] block: add allocation size check in blkdev_pr_read_keys() From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=3D660d079d90f8a1baf54d Signed-off-by: Deepanshu Kartikey --- 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" =20 +#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 *b= dev, blk_mode_t mode, if (copy_from_user(&read_keys, arg, sizeof(read_keys))) return -EFAULT; =20 - keys_info_len =3D struct_size(keys_info, keys, read_keys.num_keys); - if (keys_info_len =3D=3D SIZE_MAX) + if (read_keys.num_keys > PR_KEYS_MAX_NUM) return -EINVAL; =20 - keys_info =3D kzalloc(keys_info_len, GFP_KERNEL); + keys_info_len =3D struct_size(keys_info, keys, read_keys.num_keys); + + keys_info =3D kvzalloc(keys_info_len, GFP_KERNEL); if (!keys_info) return -ENOMEM; =20 @@ -473,7 +476,7 @@ static int blkdev_pr_read_keys(struct block_device *bde= v, blk_mode_t mode, if (copy_to_user(arg, &read_keys, sizeof(read_keys))) ret =3D -EFAULT; out: - kfree(keys_info); + kvfree(keys_info); return ret; } =20 --=20 2.43.0