CVE-2025-39691
fs/buffer: fix use-after-free when call bh_read() helper
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 end_buffer_read_sync+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.x86_64
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
<IRQ>
dump_stack_lvl+0x55/0x70
print_address_description.constprop.0+0x2c/0x390
print_report+0xb4/0x270
kasan_report+0xb8/0xf0
end_buffer_read_sync+0xe3/0x110
end_bio_bh_io_sync+0x56/0x80
blk_update_request+0x30a/0x720
scsi_end_request+0x51/0x2b0
scsi_io_completion+0xe3/0x480
? scsi_device_unbusy+0x11e/0x160
blk_complete_reqs+0x7b/0x90
handle_softirqs+0xef/0x370
irq_exit_rcu+0xa5/0xd0
sysvec_apic_timer_interrupt+0x6e/0x90
</IRQ>
Above issue happens when do ntfs3 filesystem mount, issue may happens
as follows:
mount IRQ
ntfs_fill_super
read_cache_page
do_read_cache_folio
filemap_read_folio
mpage_read_folio
do_mpage_readpage
ntfs_get_block_vbo
bh_read
submit_bh
wait_on_buffer(bh);
blk_complete_reqs
scsi_io_completion
scsi_end_request
blk_update_request
end_bio_bh_io_sync
end_buffer_read_sync
__end_buffer_read_notouch
unlock_buffer
wait_on_buffer(bh);--> return will return to caller
put_bh
--> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is
passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and
wait_on_buffer() returns to continue processing, the stack variable
is likely to be reclaimed. Consequently, during the end_buffer_read_sync()
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 drop_buffers() which
will fail to free buffers which are still locked. So it is safe to call
put_bh() before __end_buffer_read_notouch().
Produtos afetados
Linux · LinuxQuer saber se a sua infraestrutura está exposta a isto?
Falar com a TrueHacking →Referências
https://cert-portal.siemens.com/productcert/html/ssa-032379.htmlhttps://git.kernel.org/stable/c/03b40bf5d0389ca23ae6857ee25789f0e0b47ce8https://git.kernel.org/stable/c/042cf48ecf67f72c8b3846c7fac678f472712ff3https://git.kernel.org/stable/c/3169edb8945c295cf89120fc6b2c35cfe3ad4c9ehttps://git.kernel.org/stable/c/70a09115da586bf662c3bae9c0c4a1b99251fad9https://git.kernel.org/stable/c/7375f22495e7cd1c5b3b5af9dcc4f6dffe34ce49https://git.kernel.org/stable/c/90b5193edb323fefbee0e4e5bc39ed89dcc37719https://git.kernel.org/stable/c/c58c6b532b7b69537cfd9ef701c7e37cdcf79dc4https://git.kernel.org/stable/c/c5aa6ba1127307ab5dc3773eaf40d73a3423841fhttps://lists.debian.org/debian-lts-announce/2025/10/msg00007.htmlhttps://lists.debian.org/debian-lts-announce/2025/10/msg00008.html