CVE-2026-23199

In the Linux kernel, the following vulnerability has been resolved:

procfs: avoid fetching build ID while holding VMA lock

Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock

or per-VMA lock, whichever was used to lock VMA under question, to avoid

deadlock reported by syzbot:

-> #1 (&mm->mmap_lock){++++}-{4:4}:

__might_fault+0xed/0x170

_copy_to_iter+0x118/0x1720

copy_page_to_iter+0x12d/0x1e0

filemap_read+0x720/0x10a0

blkdev_read_iter+0x2b5/0x4e0

vfs_read+0x7f4/0xae0

ksys_read+0x12a/0x250

do_syscall_64+0xcb/0xf80

entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}:

__lock_acquire+0x1509/0x26d0

lock_acquire+0x185/0x340

down_read+0x98/0x490

blkdev_read_iter+0x2a7/0x4e0

__kernel_read+0x39a/0xa90

freader_fetch+0x1d5/0xa80

__build_id_parse.isra.0+0xea/0x6a0

do_procmap_query+0xd75/0x1050

procfs_procmap_ioctl+0x7a/0xb0

__x64_sys_ioctl+0x18e/0x210

do_syscall_64+0xcb/0xf80

entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1

---- ----

rlock(&mm->mmap_lock);

lock(&sb->s_type->i_mutex_key#8);

lock(&mm->mmap_lock);

rlock(&sb->s_type->i_mutex_key#8);

*** DEADLOCK ***

This seems to be exacerbated (as we haven't seen these syzbot reports

before that) by the recent:

777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")

To make this safe, we need to grab file refcount while VMA is still locked, but

other than that everything is pretty straightforward. Internal build_id_parse()

API assumes VMA is passed, but it only needs the underlying file reference, so

just add another variant build_id_parse_file() that expects file passed

directly.

[[email protected]: fix up kerneldoc]