CVE-2025-39691

In the Linux kernel, the following vulnerability has been resolved:

fs/buffer: fix use-after-free when call bh_read() helper

There's issue as follows: BUG: KASAN: stack-out-of-bounds in endbufferreadsync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x8664 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dumpstacklvl+0x55/0x70 printaddressdescription.constprop.0+0x2c/0x390 printreport+0xb4/0x270 kasanreport+0xb8/0xf0 endbufferreadsync+0xe3/0x110 endbiobhiosync+0x56/0x80 blkupdaterequest+0x30a/0x720 scsiendrequest+0x51/0x2b0 scsiiocompletion+0xe3/0x480 ? scsideviceunbusy+0x11e/0x160 blkcompletereqs+0x7b/0x90 handlesoftirqs+0xef/0x370 irqexitrcu+0xa5/0xd0 sysvecapictimer_interrupt+0x6e/0x90 </IRQ>

Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfsfillsuper readcachepage doreadcachefolio filemapreadfolio mpagereadfolio dompagereadpage ntfsgetblockvbo bhread submitbh waitonbuffer(bh); blkcompletereqs scsiiocompletion scsiendrequest blkupdaterequest endbiobhiosync endbufferreadsync _endbufferreadnotouch unlockbuffer

        wait_on_buffer(bh);--> return will return to caller

                  put_bh
                    --> trigger stack-out-of-bounds

In the mpagereadfolio() function, the stack variable 'mapbh' is passed to ntfsgetblockvbo(). Once unlockbuffer() unlocks and waitonbuffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the endbufferreadsync() process, calling put_bh() may result in stack overrun.

If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by dropbuffers() which will fail to free buffers which are still locked. So it is safe to call putbh() before _endbufferreadnotouch().