From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 93A094C10E9 for ; Thu, 17 Sep 2026 16:32:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789662755; cv=none; b=erjh8D6eoykX7yhocCw9nHrbLnvaWNpqv3Va6YahWzVFr59WHghaC0F82B/4/4d9tieaZljP9W4rujdyoNnpb0Oe03n4RDBeG+bEMwZnPXNUBegp0DmV5N62Zt7CY1hQKQqm1q+yEvAvfnJKgIZgpc/nveSb39LQgDbaquto7vk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789662755; c=relaxed/simple; bh=AiCu3XLS16z6ABuEqay9pmlp+cP60zZfaqgx2ePUtNU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=bNeFnC2gFKx0QJuWdSu66q8ZxjLVoPGN8raff0i52eq9BLroJoONBfjYUuNwrZ+Iof71Q8ATRp+a5lmEzyNN/DMQ/4q4ZeNEStGFv1wSTEn1qux+TkfvtXeyZl02hBYRJXE8xNo4j59rNNlcsvB0pKdfR9mcVs82vBGwLb8/ROA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=RDY2hwC8; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="RDY2hwC8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEB151F000FF; Thu, 17 Sep 2026 16:32:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789662754; bh=zXym+hPjTh0rA+TbKAE8UaQ2/v/dUaKoM2zmfWqE23w=; h=From:To:Cc:Subject:Date:Reply-To; b=RDY2hwC8jih7LSWZ/E8IfyTP+7j32h0xgfvRcpTuGeTEhyvtXGBOBBB33+ILoifNl 5Pq83dZUYPKDE9UcHEgs9pG6ycQsyrcR3cGmLsYvV+8O9n7ilDqvZWs0zM783oqFXL wk9aZo010ErC7M/19C3fyqOeFYFWnaQdYN6C0Uk0= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-92499: ext4: validate readdir offset before accessing dirent Date: Thu, 17 Sep 2026 17:14:49 +0100 Message-ID: <2026091726-CVE-2026-92499-bdca@gregkh> X-Mailer: git-send-email 2.55.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=4222; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=mwqL/DoOODKmKoyWKCeM7HUfc0J0A/hpL1RJzCM3ang=; b=owGbwMvMwCRo6H6F97bub03G02pJDFlrBLbd2KSwVZPx/w6215dEv5sstxfxEtFwyj/w09tzS 4nuoQmzOmJZGASZGGTFFFm+bOM5ur/ikKKXoe1pmDmsTCBDGLg4BWAit9MZ5vu95T/281DPWXOp DRvVWuJj2t+4rmaYp7rsQ+tEZvbVDipXd5mv+MHZIM1bBwA= 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: ext4: validate readdir offset before accessing dirent A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary. The Linux kernel CVE team has assigned CVE-2026-92499 to this issue. Affected and fixed versions =========================== Issue introduced in 2.6.19 with commit ac27a0ec112a089f1a5102bc8dffc79c8c815571 and fixed in 6.18.52 with commit 64d445d40e5ea4c4d4d88880db753b370cb69161 Issue introduced in 2.6.19 with commit ac27a0ec112a089f1a5102bc8dffc79c8c815571 and fixed in 7.2.6 with commit b4c728577933753180e3e97f08424d5bcaff705e Issue introduced in 2.6.19 with commit ac27a0ec112a089f1a5102bc8dffc79c8c815571 and fixed in 7.3-rc1 with commit bc4b7b0414c33b2c8898eb04386df0d21a13dad8 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-2026-92499 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/ext4/dir.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/64d445d40e5ea4c4d4d88880db753b370cb69161 https://git.kernel.org/stable/c/b4c728577933753180e3e97f08424d5bcaff705e https://git.kernel.org/stable/c/bc4b7b0414c33b2c8898eb04386df0d21a13dad8