From nobody Sun Feb 8 02:26:43 2026 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (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 DFF1532D0E2 for ; Tue, 16 Dec 2025 05:11:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765861921; cv=none; b=ajJ72DnlpGaSZcL9Ky/oblI4tGkFoDtaqTMLLrCgkzMKzXBk97FgRCX/Y5OCXkaLuASAksUirkE4b/vUcZlLg2410sUQ8HnQSKUK+y9LtTFCCaivu5JbkWRlUogo+DpbcbTb7UuFU8xA0vbeulgoO2L/CQm1kA7+P7HqPeXvDYw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765861921; c=relaxed/simple; bh=dL8XLir8PFAdyV4utDspdTI6kI2GE1B3p9S0ocnPf5Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=CJRkyt3OUwa8HUuiGqJ7IYQmX15fV8iNRr0csg7cGok9pLCh0V81tFNKiR+5jCkwvgi33o4k2TB32/O6d89MLwV361U3Fp8Xe9ERJEzX6szxOMRK5yQqbZqy04B3JXQMLC646YFYrX5QmMXfYhON5DXrt2KWpdAveXUmbcb8GpM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dYILH2Cn; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dYILH2Cn" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-34ab8e0df53so4446832a91.3 for ; Mon, 15 Dec 2025 21:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765861915; x=1766466715; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=woUyBoDp1pSghlFW7KW3gZ3nNWggNfrEo8pZzIkXJ8Y=; b=dYILH2Cn0pxiF1WRK9yhloQlTbf6+6Fr6KgRJFqXs/QjRHPGxJ/gv9EJKrdCq4wVXL 9QDnjtlTvY4oYWqE3aeJsrK91fDR/vyrs42hC5jiWB1w4iS+CT45dHKNlKofJmTa956x 7shutmkkQPUvdEmILAcmxNx9sFT8mf8BmKL3hnVkr+cbrFSl3vFAHkL7XIrv6TSqOA9K PIzbOZf5w+2qdRTo2+Ulq54AIHw9sDMVfH6ozIgKwgMZ8qA3PwdjC5w82cMZHzoF8oIq oMLW/M2OD/d3pYLm7SiSaxI/5KlXRdfv8T6TM8YbQf3srXU76TjEAeK+oI/HYlp6wjFn AAsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765861915; x=1766466715; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=woUyBoDp1pSghlFW7KW3gZ3nNWggNfrEo8pZzIkXJ8Y=; b=jhgknZqOKzbJr+cO0ay5IhwLRkn7lm8yiROhSTQNYqpYgeVoezx7RerJguGIaDFpTp EVcFfEjakE2jXKmUdgydpdRRLcLEjyEJh7PQjIEYAMa16kWdTpG6Gm8ByNbZWtAu8oMF pVUkB+4BXtykzZ3X+1suK+jTghow23VOals1ZBav5kKpGtscfXD/NmzKneODTN97q+ed K2pYHmSK4Pohj28YJTsfxHmIshAQ/MoGJ4dBbIRTKCCQ0bKJ8e/Fc6Mfc7pmoiNjnnda 4sYk9cuQyp8WgyOxYR4roaCyBw1enjmFNBjahrHM1uwqVz4+b4BSPg7ZCUC3FqQCLwfE PJBw== X-Forwarded-Encrypted: i=1; AJvYcCUBknWFTTfM5FrqH8CzxMCSf82DmyyirrGo/QKKjhFWy+8e9524u+2bSRNHCeBFxQwmR3e8EXsVZ8K8KcY=@vger.kernel.org X-Gm-Message-State: AOJu0Yx1aK6czMkrguRfWPex1RKAWmRtnXfg2LwRCCuv4aMmp7A7nckK LZ+w3xJK4fj5FHsr2uEFv0+fvpkH3eoEuJ9JgvgE98UlSpqDTcSqMNod X-Gm-Gg: AY/fxX4iem52AAJpbJjXU3+O/aIviRCyIN88HsjH7kfpii5h0eZ0KLm8v3XeS5BShA1 5hRCZwKqfKWQwDyT62Gyyu5M3EDImjU8TUzix68dhT3J0Ke0kbf1VPr2doVLHKzSwIQAQZP4Fv5 2eVpDPsCDdb2kIAuv70okK+vFIqxzdX2ZRIdjAwDt/rq9CPYaQBbF7u70lBB2bdYUabizccHxPu eO5mv53CJ0828AFebELHlagJETeotemphHwfQmbWF3xntWgdYSdtRoE0YIcmud5KMtJl7cw7xb3 GdqoE9dJNSxDFbTJk08v5fVQ7MaN+QGh3WQw0/V0TEHg7tKge8ZjHFeGqRKFTJEcvbMI1N1l0qg FkvMSKq6lOTNkYNZx0/yWpc/WK4RgeFl4XIvSWYxQ5U4geNTaFgPjajsptcFRuUoQXeQZ1hJv6J RsrT/sLl7rir8/qDiL0PCnMbEQyU728EG/A9gwm33wsESlPH9i077c2ZF6qnGO9lpwCCo= X-Google-Smtp-Source: AGHT+IGrh+0xQHXUJQbabjqcGcb7/Cq2//j72qC2/2RtwqfQw8ruWbQwRGiHSv74bArpZYdTp56LFQ== X-Received: by 2002:a17:90b:2ecc:b0:340:ad5e:cb with SMTP id 98e67ed59e1d1-34abd6cde33mr10956693a91.8.1765861914809; Mon, 15 Dec 2025 21:11:54 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:930d:e829:5a50:4004]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-34abe200077sm10539467a91.3.2025.12.15.21.11.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Dec 2025 21:11:54 -0800 (PST) From: Deepanshu Kartikey To: axboe@kernel.dk, martin.petersen@oracle.com, stefanha@redhat.com Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+660d079d90f8a1baf54d@syzkaller.appspotmail.com Subject: [PATCH v2] block: add allocation size check in blkdev_pr_read_keys() Date: Tue, 16 Dec 2025 10:41:47 +0530 Message-ID: <20251216051147.12818-1-kartikey406@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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") Tested-by: syzbot+660d079d90f8a1baf54d@syzkaller.appspotmail.com Reported-by: syzbot+660d079d90f8a1baf54d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D660d079d90f8a1baf54d Link: https://lore.kernel.org/all/20251212013510.3576091-1-kartikey406@gmai= l.com/T/ [v1] 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