CVE-2026-23002: lib/buildid: use __kernel_read() for sleepable context
In the Linux kernel, the following vulnerability has been resolved:
lib/buildid: use __kernel_read() for sleepable context
Prevent a "BUG: unable to handle kernel NULL pointer dereference in
filemap_read_folio".
For the sleepable context, convert freader to use __kernel_read() instead
of direct page cache access via read_cache_folio(). This simplifies the
faultable code path by using the standard kernel file reading interface
which handles all the complexity of reading file data.
At the moment we are not changing the code for non-sleepable context which
uses filemap_get_folio() and only succeeds if the target folios are
already in memory and up-to-date. The reason is to keep the patch simple
and easier to backport to stable kernels.
Syzbot repro does not crash the kernel anymore and the selftests run
successfully.
In the follow up we will make __kernel_read() with IOCB_NOWAIT work for
non-sleepable contexts. In addition, I would like to replace the
secretmem check with a more generic approach and will add fstest for the
buildid code.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel bug that could trigger a kernel crash from a NULL pointer dereference in a build-id file-reading path. The public record says it has been resolved in Linux stable commits, but provides no CVSS score, CWE, or business impact rating.
Executive priority
Treat as a patch-management item until severity is clarified. Prioritize high-availability Linux servers and platforms where kernel crashes could disrupt production, but do not escalate as actively exploited based on current evidence.
Technical view
The fix changes lib/buildid sleepable-context reading to use __kernel_read() instead of direct page-cache access through read_cache_folio(). The stated failure was a BUG in filemap_read_folio. Non-sleepable behavior was left mostly unchanged to keep the stable backport simple.
Likely exposure
Exposure is limited to Linux systems running affected kernel builds identified by the CVE data. The version ranges are not fully clear from the supplied record, so fleet inventory and vendor backport mapping are required.
Exploitation context
No active exploitation is reported in the provided sources, and the CVE is not marked KEV. The record mentions a syzbot reproducer causing a crash before the fix, but does not describe real-world exploitation.
Researcher notes
The evidence supports a kernel NULL pointer dereference fixed in lib/buildid read handling. Impact appears availability-oriented from the supplied text. The record lacks CVSS, CWE, precise exploitability, and clear affected-version boundaries.
Mitigation direction
Apply vendor kernel updates that include the referenced Linux stable fixes.
Confirm distro kernels have backported the lib/buildid __kernel_read() change.
If no update exists, follow vendor guidance; no workaround is provided here.
Prioritize systems where kernel crashes have high availability impact.
Validation and detection
Inventory deployed Linux kernel versions and build identifiers.
Map each kernel package to vendor advisories or the referenced stable commits.
Review kernel oops or panic logs for filemap_read_folio NULL dereference messages.
Confirm updated systems boot a kernel containing the relevant fix.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23002 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 25, 2026, 14:36 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.