From nobody Thu Dec 18 23:24:30 2025 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 76043221F39 for ; Wed, 17 Dec 2025 01:47:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765936041; cv=none; b=tXLO7u7UQHvyO5byIrNrq+OOF2MNyIsDueMwmBxQxkoW+lJpae++qrScIa4Nc9AiQHMK8y4/KetETCWHLfZ41a1AIp91ozvTc1s3qRBa/JWbmCjBEtIZiUMFLSB3N1EgDA/LvFU6HZFkIShnRr4uBrcDuEkz51vs517MKXEnLWA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765936041; c=relaxed/simple; bh=6jf/zGubgVOPjbBX+52J37PY6UVXRYaHLLG9ODYssxM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XKDcrGfYbh14dVoDdeA83niVgkALuCscRHjWQlaitTGUfBwDlQ8gBYooujuuNfZESnEabDM1sKMWTQPymI23ZnuTrCnjmTyf6idMflaT8E/+KqddfjLnWrvLp8xL2pSVCAIqZjkcpRFsWv++N1jinwObvKbmZxPjS+l+Vpaip4w= 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=VyxkSEZR; arc=none smtp.client-ip=209.85.214.176 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="VyxkSEZR" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2a099233e8dso32314945ad.3 for ; Tue, 16 Dec 2025 17:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765936040; x=1766540840; 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=IX62QACWHnPBRf5oS1mJvqi2yLF9xLlELjcpU1yBfU0=; b=VyxkSEZRpLPXhqjk6oNFTLJPLvOCv885VrcPI5KAFWtZOBoZ9aizjnGSiBExz6R6+C cLNaMdAVo3hK8/pn4mS4TppHtMI5USiQ1s98d+kvPy1Qapjgrwz7ww3UtvQarYf/U2Lr MbFv6sDT+hcbhNG65w5XFii9onUp2I/sIN0ObqfkMovUx02sjhyhH6uPnXdIVHSzLDby nGk9MvkLot2o+ueCQ1zx9KESf0rCiq7vFBOPB3P4YLVsWrHmSsZpT4cU6mAWPvxxGoog 3Z/WAGYtQaTUFA6/yMkhsRK5UASpKAQQCxmbF06+b7Yw2JY6pFa+QUnY9zXtOG5Vl5P8 nhcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765936040; x=1766540840; 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=IX62QACWHnPBRf5oS1mJvqi2yLF9xLlELjcpU1yBfU0=; b=qla1Iq9OrhlRrVT1fYH6V1XVss3KHjlyrvP7p0TynhRgQZBLV/b7L9hH6npPXurEk9 WC6RIBduJV6nXHyIwEd2CDxdp9P19dN5AC1SRyx4YA6Vx+dK5taODFm5zv3VoUIXWWfo ghMYQM7lwk1WjvLcHbi1jdISdh2Nl24EfS7eHPDyQHs1RbZAiesIb5byZ7JTXcJZFUOI FZvamyN9apa3EBdzIIQZvJZueHeS534mQ4MqBuDZkaROHHzkcHw9H3HSAcafglgoNKPD FMujhM3fgYnJukzojNMfxeRsTb+bQMcjl2rSgBOeUYGOFJnd3HqTymHl5wkGsTnOZcsD 9cUQ== X-Forwarded-Encrypted: i=1; AJvYcCWLnjnY3qsSv14E8v4tdZMg6xoqxyhqcoigIaSaknQ/CBMEBId7ue8B5nCQNZHQw1IjRDKcZHpDUjwmUr0=@vger.kernel.org X-Gm-Message-State: AOJu0YwhkmuXzQ+to5gep9/4RZ7XlUmPFf2oJIFzNV42kMqcgBpVVirG BS29rE96HlTIbymY1OlCFk9LU65Ic4mhm9Wry3Tv7SMMSiixBrFV8ruc X-Gm-Gg: AY/fxX7nFixu+7zzG817/PWN6whLLPrMT0jJoQhEPE6i/EuEczZ/pFMJZsC7qezxOII UJjjZy+2ErGVSVFlwGVm5/SxurVoxn4hhpfcJkGZlIzgfm9qCv++CjQZjRUSc7YNBqy1YcpusVl yMCvVXLEs+H0tMCa6Oi4SOOvYb8wYTTpLogUyEO4stxkSRzstVDpzKEC1l/fkeSEu8LQSpWZSNT W0NfdWOxnUcYwZdwcJVL3T5ZffdRMoh7p63VDioNgMMngSfaeypaT7cwvJEOXwNlwjltaPJRcdY RV3WN1OLopSSw22wT5lIg9nT0AjoRI1PzqxFscvSbQYR3/52W+R+YKNbNq21aeMQjaOD3MFOOm9 lPY+u5xEkVLQ4GaD+/Hzwt0P/UalSQqfm20jpLx4HWbiWSX1GFUZwXXuiy0ngXrkQcDzxsJVd9w x8R5ZuTvvpSU7Qt3BA8P02x1gCsAinZRyQiY6FxX4LbXaWMPXdRCeVDiqx92N9SvKSQK8= X-Google-Smtp-Source: AGHT+IEu90ZOwnSFrLaZzTvyYxg2VfIEgcCDuK0V8/kosm5Q28k8NN8vuywHnAi2NKtzsH+ePiT6fA== X-Received: by 2002:a17:903:244e:b0:2a0:a09a:c31f with SMTP id d9443c01a7336-2a0a09ac828mr102502835ad.8.1765936039677; Tue, 16 Dec 2025 17:47:19 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:d818:afcd:6227:33b5]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29eea0594e8sm175629965ad.87.2025.12.16.17.47.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 17:47:19 -0800 (PST) From: Deepanshu Kartikey To: axboe@kernel.dk, martin.petersen@oracle.com, stefanha@redhat.com Cc: hare@suse.de, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+660d079d90f8a1baf54d@syzkaller.appspotmail.com Subject: [PATCH v3] block: add allocation size check in blkdev_pr_read_keys() Date: Wed, 17 Dec 2025 07:17:12 +0530 Message-ID: <20251217014712.35771-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 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 Reviewed-by: Martin K. Petersen Reviewed-by: Stefan Hajnoczi --- v3: - Renamed PR_KEYS_MAX_NUM to PR_KEYS_MAX - Moved define to include/uapi/linux/pr.h 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 | 9 +++++---- include/uapi/linux/pr.h | 2 ++ 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/block/ioctl.c b/block/ioctl.c index 61feed686418..344478348a54 100644 --- a/block/ioctl.c +++ b/block/ioctl.c @@ -442,11 +442,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) 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 +474,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 diff --git a/include/uapi/linux/pr.h b/include/uapi/linux/pr.h index 847f3051057a..f0ecb1677317 100644 --- a/include/uapi/linux/pr.h +++ b/include/uapi/linux/pr.h @@ -79,4 +79,6 @@ struct pr_read_reservation { #define IOC_PR_READ_KEYS _IOWR('p', 206, struct pr_read_keys) #define IOC_PR_READ_RESERVATION _IOR('p', 207, struct pr_read_reservation) =20 +#define PR_KEYS_MAX (1u << 16) + #endif /* _UAPI_PR_H */ --=20 2.43.0