{"identifier":"CVE-2026-98538","cve":{"id":"CVE-2026-98538","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes\n\ncleanup_offline_cgwb() prepares at most WB_MAX_INODES_PER_ISW inodes\nper call and is called again until the dying wb is drained, but every\ncall walks wb->b_attached and then wb->b_dirty_time from the same end.\nInodes already prepared (they stay on the list with I_WB_SWITCH set\nuntil the switch worker runs) and inodes that cannot be switched\n(I_FREEING, I_WILL_FREE, !SB_ACTIVE, DAX, already on the target wb)\nstay where they are, so each pass rescans a growing run of them under\nwb->list_lock and a full drain is quadratic in the number of inodes on\nthe list. With ~17M inodes attached to one dying cgwb we saw this end\nin soft lockups, with CPUs reported stuck for 21-48s.\n\nWalk both lists from the oldest end and move every scanned inode to\nthe newest end, so the next pass starts where the previous one stopped\nand the drain becomes linear. b_attached is unordered, so nobody sees\nthe reorder there. b_dirty_time is ordered by dirtied_when, but the\noldest unscanned inode stays at the end move_expired_inodes() picks\nfrom, sync takes the whole list regardless of order, and prepared\ninodes leave the list as soon as the switch work runs and get a new\ndirtied_time_when on the new wb anyway, so the only inodes left out of\norder are the ones that can never switch (DAX), and only on the dying\nwb.","published":"2026-10-18T16:17:05.613000+00:00","modified":"2026-10-19T10:19:09.527000+00:00","status":"Received","score":null,"severity":"UNSCORED","vector":"","cvss_version":"","affected":[],"weaknesses":[],"references":[{"url":"https://git.kernel.org/stable/c/2d1da58c79b66646721a644c6eb4dd1f9c5c9327","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/624dd0931162523d70f9db8c120b5ec6429a9b97","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/9dac137bf77e0683778fb34c86e730c6129e8cb6","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/c96b4d1628868e1195da1a896f79e06f350a3187","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/dd4b92067238771b604b59fdda8efed6d70ee823","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/f6988c90671e83db79df1b7b9d6fdb0e5947fd84","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"kev":null,"kev_checked":true,"metrics":{},"configurations":[],"source":"nvd","retrieved_at":"2026-10-28T10:23:21.115319+00:00","exploited":false,"kev_stale":false,"products":[],"priority":{"label":"Assess exposure and vendor guidance","reasons":["No higher-priority signal is available in the current stored evidence."]},"epss":{"probability":0.00215,"percentile":0.1191,"date":"2026-10-29","stale":false},"version_assessment":null},"news":[],"campaigns":[],"domains":[{"domain":"git.kernel.org","source_url":"https://git.kernel.org/stable/c/2d1da58c79b66646721a644c6eb4dd1f9c5c9327","investigate_url":"https://investigate.aeglixmind.com/#git.kernel.org"}],"arsenal_url":"https://arsenal.aeglixmind.com/?cve=CVE-2026-98538","catalog_url":"https://cves.aeglixmind.com/cve/CVE-2026-98538","research_url":"https://investigate.aeglixmind.com/research/cve/CVE-2026-98538","coverage":{"news_candidates_checked":0,"campaign_candidates_checked":0,"bounded":false,"notice":"Exact CVE mentions in stored public excerpts and reviewed campaign content only. A mention is not proof of exploitation, attribution or tool suitability. Missing matches do not establish absence."}}