Answer in brief
CVE-2025-39878 records a Medium severity (CVSS 5.5) vulnerability in ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 5.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=0f2b2b7cacf888229cec19126e6791b11fb35f32 <4a918f04cf97b2436a8dfe5cb51bb33f8e8831f4 || >=ce80b76dd32764cc914975777e058d4fae4f0ea0 <dd1616ecbea920d228c56729461ed223cc501425 || >=ce80b76dd32764cc914975777e058d4fae4f0ea0 <249e0a47cdb46bb9eae65511c569044bd8698d7d | 4a918f04cf97b2436a8dfe5cb51bb33f8e8831f4, dd1616ecbea920d228c56729461ed223cc501425, 249e0a47cdb46bb9eae65511c569044bd8698d7d |
| Linux/Linuxgeneric | 6.15 | Not reported |
Published upstream
Sep 23, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 21, 2026
In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error The function move_dirty_folio_in_page_array() was created by commit ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") by moving code from ceph_writepages_start() to this function. This new function is supposed to return an error code which is checked by the caller (now ceph_process_folio_batch()), and on error, the caller invokes redirty_page_for_writepage() and then breaks from the loop. However, the refactoring commit has gone wrong, and it by accident, it always returns 0 (= success) because it first NULLs the pointer and then returns PTR_ERR(NULL) which is always 0. This means errors are silently ignored, leaving NULL entries in the page array, which may later crash the kernel. The simple solution is to call PTR_ERR() before clearing the pointer.
Quoted source text, attributed separately from HOL analysis.