#1153026 src:linux: CephFS folio reference leak in 6.12.115-2 (CVE-2026-52960 backport regression)

#1153026#5
Date:
2026-11-04 16:35:16 UTC
From:
To:
I would like to report a CephFS folio reference leak in Debian Trixie security kernel 6.12.115-2. The source appears to contain the two missing folio_put() calls described by CVE-2026-52960.
1. Affected kernel

  *
Running kernel: 6.12.115+deb13.1-amd64
  *
Installed binary package: linux-image-6.12.115+deb13.1-amd64
  *
Binary package version: 6.12.115-2
  *
Signed kernel source: linux-signed-amd64 6.12.115+2
  *
Corresponding Debian kernel source: linux 6.12.115-2 (trixie-security)

2. Source-level confirmation
I downloaded and extracted the Debian linux 6.12.115-2 source package and examined the patched fs/ceph/addr.c.
Within ceph_process_folio_batch(), both of the following branches release the folio lock and remove the folio from the batch without calling folio_put():

  *
Line 1323, the rc == -ENODATA branch.
  *
Line 1334, the !folio_clear_dirty_for_io(folio) branch.

In both cases the relevant sequence is:

folio_unlock(folio);
ceph_wbc->fbatch.folios[i] = NULL;
continue;

The upstream fix for CVE-2026-52960 adds folio_put(folio) between folio_unlock() and the NULL assignment in both branches.
SHA256 of the examined fs/ceph/addr.c:
97317488cd7af972759efb8669b325ac598742bf9f611006380ff506b6290b74
3. Observed failure
The issue was reproduced in a Debian 13 VM with 4 GiB RAM, using the kernel CephFS client as the rsync destination and Btrfs as the source.
The rsync systemd service had memory.high=1 GiB and memory.max=2 GiB. MGLRU was enabled (0x0007).
After sustained copying, rsync throughput collapsed and memory reclaim repeatedly scanned file folios without successfully reclaiming most of them. Memory full PSI exceeded 50%.
Kretprobe tracing of __remove_mapping() showed that failed removal attempts overwhelmingly involved CephFS folios with a reference count of 3.
The CephFS writeback queue did not exhibit sustained congestion.
4. Frozen-process reclaim experiment
I froze the rsync service using systemctl freeze and confirmed that its cgroup reported frozen=1.
After the freeze:

  *
file_dirty = 0
  *
file_writeback = 0
  *
CephFS OSD pending requests = 0
  *
File LRU remained approximately 1007 MiB
  *
memory.stat file remained approximately 15.33 MiB

I then requested 16 MiB of cgroup memory reclamation while keeping rsync frozen.
The memory.reclaim operation returned EAGAIN.
The resulting measurements were:

pgscan_direct delta: 10,651,096
pgsteal_direct delta: 2,873