From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D6721A0BE0 for ; Mon, 8 Dec 2025 00:48:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765154921; cv=none; b=VYNhW5eWBVgICXIgb5DvVEl45QGPSlBAGrW+NNHsHjum+Og94OPd5TW0KsUQSeuNbYjbjSaAnfbNw/wiRbvwrAX6onOk+USm0qWfKXprjMlU9Dr1QvJES73PIryqpdylAasFcoZ2r9iXyGpAJqfHbK85KIfUaeUH9Elpa//Z3Lk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765154921; c=relaxed/simple; bh=L2ZrrMjGIstUaDPGMRPliLE4/ZJ0d4iayvavm5S4MS8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=vF/XkSwoSqUTvfC6zC0q8VUh+jDrfMXidiMx1lDy/qH9ZJC2PWbZHjRBIghvJYhv87cWnWzUKHOVo3uECS6c2Z9IUPDK+gUTA/h/o4jwwoArpaRxgiy7i01x9m1LLVxCLHAJSQ70nPulG42R94XBr04vhqY+6b1/dfsBd5rzBY8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=WGIOx2cb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="WGIOx2cb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFCEBC19421; Mon, 8 Dec 2025 00:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1765154921; bh=L2ZrrMjGIstUaDPGMRPliLE4/ZJ0d4iayvavm5S4MS8=; h=From:To:Cc:Subject:Date:Reply-To:From; b=WGIOx2cbW2UDzLB9AR9kBfSqhw/+Bd1ACD73IqtW5THilprKZAxHHMYbSERAxtFt4 GM+S6POPcCr77aG8/UYCqw3hihCdZWpXecMtS1hquALGE5tYrKbrPJ76Djiiqm6kVd a1E6vDUe3GBp7mJz/JWnLyzIbcuZ3pceNDJrq4bU= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2025-40295: fscrypt: fix left shift underflow when inode->i_blkbits > PAGE_SHIFT Date: Mon, 8 Dec 2025 09:47:20 +0900 Message-ID: <2025120818-CVE-2025-40295-e4f2@gregkh> X-Mailer: git-send-email 2.52.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5412; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=Wa4l6YViHQUtXvvbc212RUk9u9SQRoSldzlRIUjUHGc=; b=owGbwMvMwCRo6H6F97bub03G02pJDJlmCmIBK2ed+vfKVoCtxsAsf47alD4tuR9yl/a+C/Ixv fDGKWlDRywLgyATg6yYIsuXbTxH91ccUvQytD0NM4eVCWQIAxenAEzERJthnqnP9DuV6fcUtnFc X5Kzy3/Fzpy3jgwLpk6SvWwb8XtLxasHVheWyvq7xn7zBQA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: fscrypt: fix left shift underflow when inode->i_blkbits > PAGE_SHIFT When simulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, an error trace appears during partition table reading at boot time. The issue is caused by inode->i_blkbits being larger than PAGE_SHIFT, which leads to a left shift of -1 and triggering a UBSAN warning. [ 2.697306] ------------[ cut here ]------------ [ 2.697309] UBSAN: shift-out-of-bounds in fs/crypto/inline_crypt.c:336:37 [ 2.697311] shift exponent -1 is negative [ 2.697315] CPU: 3 UID: 0 PID: 274 Comm: (udev-worker) Not tainted 6.18.0-rc2+ #34 PREEMPT(voluntary) [ 2.697317] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 2.697320] Call Trace: [ 2.697324] [ 2.697325] dump_stack_lvl+0x76/0xa0 [ 2.697340] dump_stack+0x10/0x20 [ 2.697342] __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 [ 2.697351] bh_get_inode_and_lblk_num.cold+0x12/0x94 [ 2.697359] fscrypt_set_bio_crypt_ctx_bh+0x44/0x90 [ 2.697365] submit_bh_wbc+0xb6/0x190 [ 2.697370] block_read_full_folio+0x194/0x270 [ 2.697371] ? __pfx_blkdev_get_block+0x10/0x10 [ 2.697375] ? __pfx_blkdev_read_folio+0x10/0x10 [ 2.697377] blkdev_read_folio+0x18/0x30 [ 2.697379] filemap_read_folio+0x40/0xe0 [ 2.697382] filemap_get_pages+0x5ef/0x7a0 [ 2.697385] ? mmap_region+0x63/0xd0 [ 2.697389] filemap_read+0x11d/0x520 [ 2.697392] blkdev_read_iter+0x7c/0x180 [ 2.697393] vfs_read+0x261/0x390 [ 2.697397] ksys_read+0x71/0xf0 [ 2.697398] __x64_sys_read+0x19/0x30 [ 2.697399] x64_sys_call+0x1e88/0x26a0 [ 2.697405] do_syscall_64+0x80/0x670 [ 2.697410] ? __x64_sys_newfstat+0x15/0x20 [ 2.697414] ? x64_sys_call+0x204a/0x26a0 [ 2.697415] ? do_syscall_64+0xb8/0x670 [ 2.697417] ? irqentry_exit_to_user_mode+0x2e/0x2a0 [ 2.697420] ? irqentry_exit+0x43/0x50 [ 2.697421] ? exc_page_fault+0x90/0x1b0 [ 2.697422] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2.697425] RIP: 0033:0x75054cba4a06 [ 2.697426] Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 [ 2.697427] RSP: 002b:00007fff973723a0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 [ 2.697430] RAX: ffffffffffffffda RBX: 00005ea9a2c02760 RCX: 000075054cba4a06 [ 2.697432] RDX: 0000000000002000 RSI: 000075054c190000 RDI: 000000000000001b [ 2.697433] RBP: 00007fff973723c0 R08: 0000000000000000 R09: 0000000000000000 [ 2.697434] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 2.697434] R13: 00005ea9a2c027c0 R14: 00005ea9a2be5608 R15: 00005ea9a2be55f0 [ 2.697436] [ 2.697436] ---[ end trace ]--- This situation can happen for block devices because when CONFIG_TRANSPARENT_HUGEPAGE is enabled, the maximum logical_block_size is 64 KiB. set_init_blocksize() then sets the block device inode->i_blkbits to 13, which is within this limit. File I/O does not trigger this problem because for filesystems that do not support the FS_LBS feature, sb_set_blocksize() prevents sb->s_blocksize_bits from being larger than PAGE_SHIFT. During inode allocation, alloc_inode()->inode_init_always() assigns inode->i_blkbits from sb->s_blocksize_bits. Currently, only xfs_fs_type has the FS_LBS flag, and since xfs I/O paths do not reach submit_bh_wbc(), it does not hit the left-shift underflow issue. [EB: use folio_pos() and consolidate the two shifts by i_blkbits] The Linux kernel CVE team has assigned CVE-2025-40295 to this issue. Affected and fixed versions =========================== Issue introduced in 6.15 with commit 47dd67532303803a87f43195e088b3b4bcf0454d and fixed in 6.17.8 with commit dde026c5d2a5870f97924d5b512adf2b93fb7153 Issue introduced in 6.15 with commit 47dd67532303803a87f43195e088b3b4bcf0454d and fixed in 6.18 with commit 1e39da974ce621ed874c6d3aaf65ad14848c9f0d Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2025-40295 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/crypto/inline_crypt.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/dde026c5d2a5870f97924d5b512adf2b93fb7153 https://git.kernel.org/stable/c/1e39da974ce621ed874c6d3aaf65ad14848c9f0d