Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections<br /> <br /> syzbot reported a general protection fault in vidtv_psi_desc_assign [1].<br /> <br /> vidtv_psi_pmt_stream_init() can return NULL on memory allocation<br /> failure, but vidtv_channel_pmt_match_sections() does not check for<br /> this. When tail is NULL, the subsequent call to<br /> vidtv_psi_desc_assign(&amp;tail-&gt;descriptor, desc) dereferences a NULL<br /> pointer offset, causing a general protection fault.<br /> <br /> Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean<br /> up the already-allocated stream chain and return.<br /> <br /> [1]<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629<br /> Call Trace:<br /> <br /> vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline]<br /> vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479<br /> vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519<br /> vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]<br /> vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: Handle invalid large leaf mappings correctly<br /> <br /> It has been possible for a long time to mark ptes in the linear map as<br /> invalid. This is done for secretmem, kfence, realm dma memory un/share,<br /> and others, by simply clearing the PTE_VALID bit. But until commit<br /> a166563e7ec37 ("arm64: mm: support large block mapping when<br /> rodata=full") large leaf mappings were never made invalid in this way.<br /> <br /> It turns out various parts of the code base are not equipped to handle<br /> invalid large leaf mappings (in the way they are currently encoded) and<br /> I&amp;#39;ve observed a kernel panic while booting a realm guest on a<br /> BBML2_NOABORT system as a result:<br /> <br /> [ 15.432706] software IO TLB: Memory encryption is active and system is using DMA bounce buffers<br /> [ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000<br /> [ 15.513762] Mem abort info:<br /> [ 15.527245] ESR = 0x0000000096000046<br /> [ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 15.572146] SET = 0, FnV = 0<br /> [ 15.592141] EA = 0, S1PTW = 0<br /> [ 15.612694] FSC = 0x06: level 2 translation fault<br /> [ 15.640644] Data abort info:<br /> [ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> [ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> [ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000<br /> [ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704<br /> [ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP<br /> [ 15.886394] Modules linked in:<br /> [ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT<br /> [ 15.935258] Hardware name: linux,dummy-virt (DT)<br /> [ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c<br /> [ 16.006163] lr : swiotlb_bounce+0xf4/0x158<br /> [ 16.024145] sp : ffff80008000b8f0<br /> [ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000<br /> [ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0<br /> [ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc<br /> [ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974<br /> [ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018<br /> [ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000<br /> [ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000<br /> [ 16.349071] Call trace:<br /> [ 16.360143] __pi_memcpy_generic+0x128/0x22c (P)<br /> [ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4<br /> [ 16.400282] swiotlb_map+0x5c/0x228<br /> [ 16.415984] dma_map_phys+0x244/0x2b8<br /> [ 16.432199] dma_map_page_attrs+0x44/0x58<br /> [ 16.449782] virtqueue_map_page_attrs+0x38/0x44<br /> [ 16.469596] virtqueue_map_single_attrs+0xc0/0x130<br /> [ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc<br /> [ 16.510355] try_fill_recv+0x2a4/0x584<br /> [ 16.526989] virtnet_open+0xd4/0x238<br /> [ 16.542775] __dev_open+0x110/0x24c<br /> [ 16.558280] __dev_change_flags+0x194/0x20c<br /> [ 16.576879] netif_change_flags+0x24/0x6c<br /> [ 16.594489] dev_change_flags+0x48/0x7c<br /> [ 16.611462] ip_auto_config+0x258/0x1114<br /> [ 16.628727] do_one_initcall+0x80/0x1c8<br /> [ 16.645590] kernel_init_freeable+0x208/0x2f0<br /> [ 16.664917] kernel_init+0x24/0x1e0<br /> [ 16.680295] ret_from_fork+0x10/0x20<br /> [ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c)<br /> [ 16.723106] ---[ end trace 0000000000000000 ]---<br /> [ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> [ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff8000800000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY<br /> <br /> filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY,<br /> as documented in mm/filemap.c:<br /> <br /> "If our return value has VM_FAULT_RETRY set, it&amp;#39;s because the mmap_lock<br /> may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."<br /> <br /> When this happens, a concurrent munmap() can call remove_vma() and free<br /> the vm_area_struct via RCU. The saved &amp;#39;vma&amp;#39; pointer in ocfs2_fault() then<br /> becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call<br /> dereferences it -- a use-after-free.<br /> <br /> Fix this by saving ip_blkno as a plain integer before calling<br /> filemap_fault(), and removing vma from the trace event. Since<br /> ip_blkno is copied by value before the lock can be dropped, it<br /> remains valid regardless of what happens to the vma or inode<br /> afterward.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: handle invalid dinode in ocfs2_group_extend<br /> <br /> [BUG]<br /> kernel BUG at fs/ocfs2/resize.c:308!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308<br /> Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe<br /> Call Trace:<br /> ...<br /> ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583<br /> x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> <br /> [CAUSE]<br /> ocfs2_group_extend() assumes that the global bitmap inode block<br /> returned from ocfs2_inode_lock() has already been validated and<br /> BUG_ONs when the signature is not a dinode. That assumption is too<br /> strong for crafted filesystems because the JBD2-managed buffer path<br /> can bypass structural validation and return an invalid dinode to the<br /> resize ioctl.<br /> <br /> [FIX]<br /> Validate the dinode explicitly in ocfs2_group_extend(). If the global<br /> bitmap buffer does not contain a valid dinode, report filesystem<br /> corruption with ocfs2_error() and fail the resize operation instead of<br /> crashing the kernel.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup<br /> <br /> Disable the delayed work before clearing BAR mappings and doorbells to<br /> avoid running the handler after resources have been torn down.<br /> <br /> Unable to handle kernel paging request at virtual address ffff800083f46004<br /> [...]<br /> Internal error: Oops: 0000000096000007 [#1] SMP<br /> [...]<br /> Call trace:<br /> epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P)<br /> process_one_work+0x154/0x3b0<br /> worker_thread+0x2c8/0x400<br /> kthread+0x148/0x210<br /> ret_from_fork+0x10/0x20

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown<br /> <br /> epf_ntb_epc_destroy() duplicates the teardown that the caller is<br /> supposed to perform later. This leads to an oops when .allow_link fails<br /> or when .drop_link is performed. The following is an example oops of the<br /> former case:<br /> <br /> Unable to handle kernel paging request at virtual address dead000000000108<br /> [...]<br /> [dead000000000108] address between user and kernel address ranges<br /> Internal error: Oops: 0000000096000044 [#1] SMP<br /> [...]<br /> Call trace:<br /> pci_epc_remove_epf+0x78/0xe0 (P)<br /> pci_primary_epc_epf_link+0x88/0xa8<br /> configfs_symlink+0x1f4/0x5a0<br /> vfs_symlink+0x134/0x1d8<br /> do_symlinkat+0x88/0x138<br /> __arm64_sys_symlinkat+0x74/0xe0<br /> [...]<br /> <br /> Remove the helper, and drop pci_epc_put(). EPC device refcounting is<br /> tied to the configfs EPC group lifetime, and pci_epc_put() in the<br /> .drop_link path is sufficient.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix possible deadlock between unlink and dio_end_io_write<br /> <br /> ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,<br /> while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.<br /> This creates an ABBA lock ordering violation on lock classes<br /> ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and<br /> ocfs2_file_ip_alloc_sem_key.<br /> <br /> Lock Chain #0 (orphan dir inode_lock -&gt; ip_alloc_sem):<br /> ocfs2_unlink<br /> ocfs2_prepare_orphan_dir<br /> ocfs2_lookup_lock_orphan_dir<br /> inode_lock(orphan_dir_inode) ip_alloc_sem) orphan dir inode_lock):<br /> ocfs2_dio_end_io_write<br /> down_write(&amp;oi-&gt;ip_alloc_sem)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm-&gt;lock<br /> <br /> Take and hold kvm-&gt;lock for before checking sev_guest() in<br /> sev_mem_enc_register_region(), as sev_guest() isn&amp;#39;t stable unless kvm-&gt;lock<br /> is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can&amp;#39;t<br /> rollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to<br /> a not-yet-initialized sev-&gt;regions_list, e.g. triggering a #GP<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE<br /> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024<br /> RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83<br /> Code: 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00<br /> RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256<br /> RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000<br /> RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000<br /> RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000<br /> R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000<br /> R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000<br /> FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371<br /> kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363<br /> __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51<br /> do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f34e9f7e9a9<br /> Code: 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9<br /> RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007<br /> RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8<br /> <br /> <br /> with a syzlang reproducer that looks like:<br /> <br /> syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000040)={0x0, &amp;(0x7f0000000180)=ANY=[], 0x70}) (async)<br /> syz_kvm_add_vcpu$x86(0x0, &amp;(0x7f0000000080)={0x0, &amp;(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async)<br /> r0 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000200), 0x0, 0x0)<br /> r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)<br /> r2 = openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000240), 0x0, 0x0)<br /> r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0)<br /> ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &amp;(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async)<br /> ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &amp;(0x7f0000000280)={[...], 0x5}) (async)<br /> ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async)<br /> r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0)<br /> openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async)<br /> ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &amp;(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &amp;(0x7f0000001000/0x2000)=nil}) (async)<br /> r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2)<br /> close(r0) (async)<br /> openat$kvm(0xffffffffffffff9c, &amp;(0x7f0000000000), 0x8000, 0x0) (async)<br /> ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &amp;(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async)<br /> ioctl$KVM_RUN(r5, 0xae80, 0x0)<br /> <br /> Opportunistically use guard() to avoid having to define a new error label<br /> and goto usage.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finish<br /> <br /> Lock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, as<br /> allowing userspace to manipulate and/or run a vCPU while its state is being<br /> synchronized would at best corrupt vCPU state, and at worst crash the host<br /> kernel.<br /> <br /> Opportunistically assert that vcpu-&gt;mutex is held when synchronizing its<br /> VMSA (the SEV-ES path already locks vCPUs).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION<br /> <br /> Drop the WARN in sev_pin_memory() on npages overflowing an int, as the<br /> WARN is comically trivially to trigger from userspace, e.g. by doing:<br /> <br /> struct kvm_enc_region range = {<br /> .addr = 0,<br /> .size = -1ul,<br /> };<br /> <br /> __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &amp;range);<br /> <br /> Note, the checks in sev_mem_enc_register_region() that presumably exist to<br /> verify the incoming address+size are completely worthless, as both "addr"<br /> and "size" are u64s and SEV is 64-bit only, i.e. they _can&amp;#39;t_ be greater<br /> than ULONG_MAX. That wart will be cleaned up in the near future.<br /> <br /> if (range-&gt;addr &gt; ULONG_MAX || range-&gt;size &gt; ULONG_MAX)<br /> return -EINVAL;<br /> <br /> Opportunistically add a comment to explain why the code calculates the<br /> number of pages the "hard" way, e.g. instead of just shifting @ulen.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU<br /> <br /> Reject synchronizing vCPU state to its associated VMSA if the vCPU has<br /> already been launched, i.e. if the VMSA has already been encrypted. On a<br /> host with SNP enabled, accessing guest-private memory generates an RMP #PF<br /> and panics the host.<br /> <br /> BUG: unable to handle page fault for address: ff1276cbfdf36000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x80000003) - RMP violation<br /> PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163<br /> SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f]<br /> Oops: Oops: 0003 [#1] SMP NOPTI<br /> CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023<br /> RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd]<br /> Call Trace:<br /> <br /> snp_launch_update_vmsa+0x19d/0x290 [kvm_amd]<br /> snp_launch_finish+0xb6/0x380 [kvm_amd]<br /> sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd]<br /> kvm_arch_vm_ioctl+0x837/0xcf0 [kvm]<br /> kvm_vm_ioctl+0x3fd/0xcc0 [kvm]<br /> __x64_sys_ioctl+0xa3/0x100<br /> x64_sys_call+0xfe0/0x2350<br /> do_syscall_64+0x81/0x10f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7ffff673287d<br /> <br /> <br /> Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM:<br /> Provide support to launch and run an SEV-ES guest"), but has only been<br /> actively dangerous for the host since SNP support was added. With SEV-ES,<br /> KVM would "just" clobber guest state, which is totally fine from a host<br /> kernel perspective since userspace can clobber guest state any time before<br /> sev_launch_update_vmsa().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: call -&gt;free_folio() directly in folio_unmap_invalidate()<br /> <br /> We can only call filemap_free_folio() if we have a reference to (or hold a<br /> lock on) the mapping. Otherwise, we&amp;#39;ve already removed the folio from the<br /> mapping so it no longer pins the mapping and the mapping can be removed,<br /> causing a use-after-free when accessing mapping-&gt;a_ops.<br /> <br /> Follow the same pattern as __remove_mapping() and load the free_folio<br /> function pointer before dropping the lock on the mapping. That lets us<br /> make filemap_free_folio() static as this was the only caller outside<br /> filemap.c.