{"id":"CVE-2026-98832","kind":"vulnerability","aliases":["CVE-2026-98832"],"related":[],"title":"Linux kernel: blk-cgroup lock wrongly re-enables interrupts, risking deadlock","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: save IRQ state in blkg_tryget_closest()\n\nbio_set_dev() associates the bio with a blkg through bio_associate_blkg().\nIf the blkg lookup misses, blkg_tryget_closest() takes q->queue_lock with\nspin_lock_irq() and releases it with spin_unlock_irq(), which\nunconditionally enables local interrupts.\n\nCallers may call bio_set_dev() with interrupts already disabled, e.g.\ndm-thin's pool_map() does so while holding pool->lock taken with\nspin_lock_irq().  The nested spin_unlock_irq() then enables interrupts\nwhile pool->lock is still held, so an I/O completion softirq can run on\nthe same CPU, re-acquire pool->lock (thin_endio(), or overwrite_endio()\n-> complete_mapping_preparation()) and deadlock.  lockdep reports this\nas inconsistent SOFTIRQ-ON-W to IN-SOFTIRQ-W usage.\n\nCommit 3a762de55b4e (\"block: save irq state in blkg_lookup_create()\")\nfixed the same problem while the lock lived in blkg_lookup_create(), but\ncommit 9327a865e395 (\"blk-cgroup: don't nest queue_lock under rcu in\nblkg_lookup_create()\") moved the locking into blkg_tryget_closest() and\nreverted it to spin_lock_irq().\n\nSave and restore the caller's IRQ state instead.","summary":"In the Linux kernel's block cgroup code, a lock helper unconditionally re-enables interrupts even when the caller already had them disabled, which can let a completion softirq re-acquire a held lock. The sources describe this as a deadlock in device-mapper thin provisioning (dm-thin) that lockdep flags, and the fix saves and restores the caller's interrupt state.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["device-mapper","dm-thin","linux-kernel","other","self-hosted"],"not_affected_if":["no-blk-cgroup","no-dm-thin"],"how_to_check":"- unknown","fix":"- Update to a Linux kernel release that includes the commit 'blk-cgroup: save IRQ state in blkg_tryget_closest()'; the sources do not list fixed versions.","status":"open","published_at":"2026-10-18T16:17:37+00:00","first_seen_at":"2026-10-23T21:57:17+00:00","triaged_at":"2026-10-25T05:13:21+00:00","updated_at":"2026-10-25T05:13:21+00:00","category":"other","confidence":0.6,"triage":{"at":"2026-10-25T05:13:21Z","model":"claude-haiku-5-5","output":{"fix":"- Update to a Linux kernel release that includes the commit 'blk-cgroup: save IRQ state in blkg_tryget_closest()'; the sources do not list fixed versions.","reach":"local","title":"Linux kernel: blk-cgroup lock wrongly re-enables interrupts, risking deadlock","impact":"low","summary":"In the Linux kernel's block cgroup code, a lock helper unconditionally re-enables interrupts even when the caller already had them disabled, which can let a completion softirq re-acquire a held lock. The sources describe this as a deadlock in device-mapper thin provisioning (dm-thin) that lockdep flags, and the fix saves and restores the caller's interrupt state.","category":"other","nicknames":[],"who_cares":["linux-kernel","device-mapper","dm-thin","self-hosted"],"confidence":0.6,"needs_auth":"unknown","worst_case":"kernel deadlock causing a hang or denial of service on the machine","analyst_note":"Check the kernel.org stable commit and NVD entry for fixed kernel versions and CVSS; the sources give no version list or severity.","how_to_check":"- unknown","needs_analyst":true,"not_affected_if":["no-dm-thin","no-blk-cgroup"],"who_is_affected":"Systems running a Linux kernel with block cgroups and device-mapper thin pools (dm-thin) are the likely candidates, since the deadlock path runs through dm-thin's pool_map(). Machines without dm-thin or without block cgroup I/O use are unlikely to hit the path. The sources do not say how often the deadlock occurs in practice.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.000674,"input_tokens":3729,"output_tokens":603,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':15A,18A '-98832':16A,19A '3a762de55b4e':244C '9327a865e395':267C 'acquir':65B,215C 'alreadi':53B,168C 'associ':122C,130C 'bio':119C,124C,129C,163C 'blk':4A,110C,269C 'blk-cgroup':3A,109C,268C 'blkg':116C,127C,131C,134C,137C,250C,262C,279C,286C 'block':38B,245C 'call':162C 'caller':52B,95B,160C,300C 'cgroup':5A,39B,111C,270C 'closest':118C,139C,288C 'code':40B 'commit':243C,266C 'complet':61B,205C,223C 'cpu':212C 'creat':252C,264C,281C 'cve':14A,17A 'deadlock':13A,75B,227C 'describ':71B 'dev':121C,165C 'devic':21B,78B 'device-mapp':20B,77B 'disabl':56B,169C 'dm':24B,83B,172C 'dm-thin':23B,82B,171C 'e.g':170C 'enabl':10A,47B,157C,194C 'endio':219C,222C 'even':49B 'fix':90B,253C 'flag':87B 'follow':104C 'held':67B,201C 'helper':43B 'hold':180C 'host':32B 'i/o':204C 'in-softirq-w':238C 'inconsist':232C 'instead':304C 'interrupt':11A,48B,97B,159C,167C,195C 'irq':113C,147C,154C,187C,192C,247C,295C,302C 'kernel':2A,28B,36B,102C 'let':59B 'linux':1A,27B,35B,101C 'linux-kernel':26B 'live':260C 'local':158C 'lock':6A,42B,68B,143C,146C,182C,186C,198C,217C,259C,275C,284C,294C 'lockdep':86B,228C 'lookup':135C,251C,263C,280C 'map':176C,224C 'mapper':22B,79B 'may':161C 'miss':136C 'move':282C 'nest':189C,273C 'overwrit':221C 'pool':175C,181C,197C,216C 'prepar':225C 'problem':256C 'provis':81B 'q':141C 'queue':142C,274C 'rcu':277C 're':9A,46B,64B,214C 're-acquir':63B,213C 're-en':8A,45B 'releas':149C 'report':229C 'resolv':108C 'restor':93B,298C 'revert':290C 'risk':12A 'run':208C 'save':91B,112C,246C,296C 'self':31B 'self-host':30B 'set':120C,164C 'softirq':62B,206C,234C,240C 'softirq-on-w':233C 'sourc':70B 'spin':145C,152C,185C,190C,293C 'state':98B,114C,248C,303C 'still':200C 'take':140C 'taken':183C 'thin':25B,80B,84B,173C,218C 'tryget':117C,138C,287C 'uncondit':44B,156C 'unlock':153C,191C 'usag':242C 'vulner':105C 'w':236C,241C 'wrong':7A","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel with block cgroups and device-mapper thin pools (dm-thin) are the likely candidates, since the deadlock path runs through dm-thin's pool_map(). Machines without dm-thin or without block cgroup I/O use are unlikely to hit the path. The sources do not say how often the deadlock occurs in practice.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-18T16:17:37+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98832","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98832","severity":null,"published_at":"2026-10-18T16:17:37+00:00","modified_at":"2026-10-19T10:19:47+00:00","first_seen_at":"2026-10-23T21:57:17+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"}