CVE-2023-52566

What it actually does

Use-after-free in nilfs_gccache_submit_read_data() where brelse(bh) can free the buffer head before bh->b_page is dereferenced after a failed nilfs_dat_translate() call during nilfs2 garbage collection.

Why it matters to the business

Kernel instability or potential privilege escalation on systems using the nilfs2 filesystem when garbage collection is triggered via modified userland tools or direct ioctls; low prevalence due to niche filesystem usage.

How an attack unfolds

An attacker modifies the userland GC library or invokes the GC ioctl directly to force the nilfs_dat_translate() failure path, causing the buffer head to be released and later dereferenced after free.

How to fix it

Update the Linux kernel to the fixed commit fb1084e63ee56958b0a56e17a50a4fd86445b9c1 or later stable version containing the patch that moves the brelse operation after page unlock and put.

How to confirm the fix worked

Confirm the kernel source contains the commit fb1084e63ee56958b0a56e17a50a4fd86445b9c1; test that nilfs_gccache_submit_read_data() no longer dereferences after brelse by reviewing the updated function logic.

Typical attack path

1. Identify a system using nilfs2 filesystem
2. Modify userland GC tools or directly call the GC ioctl to trigger the vulnerable code path
3. Force nilfs_dat_translate() failure to invoke brelse(bh)
4. Trigger dereference of bh->b_page on the now-freed buffer head

How to detect it

Review kernel logs for nilfs2 GC-related oops or use-after-free warnings; inspect for unexpected calls to nilfs_gccache_submit_read_data via ftrace or similar tracing during garbage collection operations.

What your security team should do

• Apply the kernel patch immediately on any systems using nilfs2
• Audit for nilfs2 usage across the environment
• Disable or restrict direct access to nilfs2 GC ioctls where possible
• Monitor for future nilfs2-related kernel updates