{"id":"AZL-101972","summary":"CVE-2026-92499 affecting package kernel 6.6.150.1-1","details":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: validate readdir offset before accessing dirent\n\nA corrupted directory can trigger the following KASAN report when\next4_readdir() resumes from an invalid position:\n\n  BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820\n  Read of size 2 at addr ffff88810a646000 by task repro_linear/509\n\n  Call Trace:\n   \u003cTASK\u003e\n   dump_stack_lvl+0x53/0x70\n   print_report+0xd0/0x630\n   kasan_report+0xce/0x100\n   __ext4_check_dir_entry+0x5ef/0x820\n   ext4_readdir+0xcde/0x2b70\n   iterate_dir+0x1a1/0x520\n   __x64_sys_getdents64+0x12b/0x220\n   do_syscall_64+0xf9/0x540\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   \u003c/TASK\u003e\n\nKASAN reports use-after-free because the out-of-bounds access lands in an\nadjacent freed page. The directory buffer itself is still referenced.\n\next4_dir_llseek() invalidates the directory cookie so that ext4_readdir()\nrescans directory entries from the start of the block. The rescan checks\nonly the lower bound of rec_len before advancing. A corrupted rec_len can\ntherefore place the offset where the block has insufficient space for a\ncomplete directory entry. The rescan itself may dereference that truncated\nentry, or the main loop may pass it to __ext4_check_dir_entry(). The latter\nreads de-\u003erec_len before validating the range. For example:\n\n  block offset  0                           4092  4096\n                |---- de1.rec_len = 4092 -----|----|\n                                               de2.inode\n                                                    | de2.rec_len\n                                                    ^ OOB, reported as UAF\n\nde2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in\nthe block, but its rec_len starts at offset 4096 and crosses the boundary.\n\nThe minimum safe length is inode-dependent. Encrypted and casefolded\ndirectory entries need eight additional hash bytes, while a valid metadata\nchecksum tail is only 12 bytes.\n\nCache the metadata checksum feature state and derive the minimum directory\nentry length from the on-disk format. Use it to bound both the rescan and\nthe offset passed to the main loop. Report an offset in a truncated block\ntail and skip the remainder of the block, while continuing to accept an\noffset exactly at the block boundary.","modified":"2026-09-19T05:33:49Z","published":"2026-09-17T17:17:52Z","upstream":["CVE-2026-92499"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-92499"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.6.150.1-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-101972.json"}}],"schema_version":"1.9.0"}