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