https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 21:31:20 +0000 https://vulnerability.circl.lu/vuln/cve-2026-23056 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>uacce: implement mremap in uacce_vm_ops to return -EPERM</p> <p>The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users.</p> <p>The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario:</p> <p>An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma&#39;s vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q-&gt;qfr to be freed twice(qfr will be set to null here, so repeated release is ok).</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>uacce: implement mremap in uacce_vm_ops to return -EPERM</p> <p>The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users.</p> <p>The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario:</p> <p>An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma&#39;s vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q-&gt;qfr to be freed twice(qfr will be set to null here, so repeated release is ok).</p> https://vulnerability.circl.lu/vuln/cve-2026-23056