{"id":"CVE-2026-98538","kind":"vulnerability","aliases":["CVE-2026-98538"],"related":[],"title":"Linux kernel: writeback cleanup rescans inodes quadratically, causing lockups","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.","summary":"When a memory cgroup's writeback context is torn down with millions of inodes attached, the kernel rescans the same inodes on every pass, so draining the list takes quadratic time and can freeze CPUs for tens of seconds. The sources describe a denial-of-service style stall from a kernel bug, not a confirmed code execution or data-theft path.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["kubernetes","linux-kernel","other","self-hosted"],"not_affected_if":["unknown"],"how_to_check":"- `uname -r` and compare against the kernel version that contains the upstream fix for CVE-2026-98538 (unknown in the sources)\n- Check whether the host runs many inodes on memory cgroups with heavy file churn, e.g. `cat /proc/meminfo | grep -i dirty` showing large dirty values during cgroup teardown","fix":"- Update the Linux kernel to a stable release that includes the upstream commit for CVE-2026-98538 (version unknown in the sources)\n- Follow your distribution's kernel advisory for the fixed package","status":"open","published_at":"2026-10-18T16:17:05+00:00","first_seen_at":"2026-10-23T21:57:15+00:00","triaged_at":"2026-10-25T05:23:45+00:00","updated_at":"2026-10-25T05:23:45+00:00","category":"other","confidence":0.4,"triage":{"at":"2026-10-25T05:23:45Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a stable release that includes the upstream commit for CVE-2026-98538 (version unknown in the sources)\n- Follow your distribution's kernel advisory for the fixed package","reach":"local","title":"Linux kernel: writeback cleanup rescans inodes quadratically, causing lockups","impact":"low","summary":"When a memory cgroup's writeback context is torn down with millions of inodes attached, the kernel rescans the same inodes on every pass, so draining the list takes quadratic time and can freeze CPUs for tens of seconds. The sources describe a denial-of-service style stall from a kernel bug, not a confirmed code execution or data-theft path.","category":"other","nicknames":[],"who_cares":["linux-kernel","self-hosted","kubernetes"],"confidence":0.4,"needs_auth":"unknown","worst_case":"Kernel CPUs stall for tens of seconds, causing denial of service","analyst_note":"Find the affected and fixed kernel versions and the stable commit for CVE-2026-98538 at NVD or the kernel git tree.","how_to_check":"- `uname -r` and compare against the kernel version that contains the upstream fix for CVE-2026-98538 (unknown in the sources)\n- Check whether the host runs many inodes on memory cgroups with heavy file churn, e.g. `cat /proc/meminfo | grep -i dirty` showing large dirty values during cgroup teardown","needs_analyst":true,"not_affected_if":["unknown"],"who_is_affected":"Systems running a Linux kernel with the affected writeback code, most likely hosts that create and tear down many memory cgroups with a large number of cached inodes. The sources do not say which kernel versions are affected, so treat any unpatched kernel as in scope until the fixed version is confirmed.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"unknown"},"cost_usd":0.00071,"input_tokens":3766,"output_tokens":667,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':11A,14A '-48':237C '-98538':12A,15A '17m':217C '21':236C 'activ':178C 'alreadi':149C,180C 'anyway':334C 'attach':38B,137C,219C,271C 'b':136C,141C,270C,280C 'becom':268C 'bound':98C 'bug':76B 'call':120C,123C,133C 'cannot':169C 'caus':8A 'cgroup':27B 'cgwb':101C,109C,223C 'cleanup':4A,99C,107C 'code':80B 'confirm':79B 'context':30B 'cpus':58B,232C 'cve':10A,13A 'data':84B 'data-theft':83B 'dax':179C,350C 'denial':68B 'denial-of-servic':67B 'describ':65B 'die':127C,222C,355C 'dirti':142C,281C,286C,327C 'drain':49B,130C,205C,267C 'end':147C,227C,245C,254C,296C 'everi':46B,132C,248C 'execut':81B 'expir':298C 'follow':92C 'free':173C,176C 'freez':57B 'full':204C 'get':324C 'grow':194C 'host':23B 'inod':6A,37B,44B,106C,115C,118C,148C,167C,212C,218C,250C,292C,299C,312C,338C 'isw':117C 'kernel':2A,19B,40B,75B,90C 'kubernet':16B 'leav':313C 'left':339C 'linear':269C 'linux':1A,18B,89C 'linux-kernel':17B 'list':51B,155C,200C,215C,241C,306C,315C 'lock':201C 'lockup':9A,230C 'max':114C 'memori':26B 'million':35B 'move':247C,297C 'never':348C 'new':326C,332C 'newest':253C 'next':257C 'nobodi':275C 'number':210C 'offlin':100C,108C 'oldest':244C,290C 'one':221C,263C,345C 'order':284C,309C,342C 'pass':47B,191C,258C 'path':86B 'per':116C,119C 'pick':300C 'prepar':110C,150C,311C 'previous':262C 'quadrat':7A,53B,207C 'regardless':307C 'reorder':278C 'report':233C 'rescan':5A,41B,102C,192C 'resolv':96C 'rotat':104C 'run':165C,195C,322C 'saw':225C 'sb':177C 'scan':105C,249C 'second':62B 'see':276C 'self':22B 'self-host':21B 'servic':70B 'set':160C 'soft':229C 'soon':317C 'sourc':64B 'stall':72B 'start':259C 'stay':152C,185C,293C 'stop':264C 'stuck':234C 'style':71B 'switch':159C,163C,171C,320C,349C 'sync':302C 'take':52B,303C 'target':183C 'ten':60B 'theft':85B 'time':54B,143C,282C,328C 'torn':32B 'unord':273C 'unscan':291C 'vulner':93C 'walk':134C,239C 'wb':113C,128C,135C,140C,158C,184C,199C,333C,356C 'whole':305C 'work':321C 'worker':164C 'writeback':3A,29B,97C","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel with the affected writeback code, most likely hosts that create and tear down many memory cgroups with a large number of cached inodes. The sources do not say which kernel versions are affected, so treat any unpatched kernel as in scope until the fixed version is confirmed.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-18T16:17:05+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98538","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98538","severity":null,"published_at":"2026-10-18T16:17:05+00:00","modified_at":"2026-10-19T10:19:09+00:00","first_seen_at":"2026-10-23T21:57:15+00:00","fetched_at":"2026-10-23T22:28:56+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}