kernel/drivers/uio, branch linux-6.9.y

Merge tag 'hyperv-fixes-signed-20240411' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux

2024-04-11T23:23:56Z

Pull hyperv fixes from Wei Liu: - Some cosmetic changes (Erni Sri Satya Vennela, Li Zhijian) - Introduce hv_numa_node_to_pxm_info() (Nuno Das Neves) - Fix KVP daemon to handle IPv4 and IPv6 combination for keyfile format (Shradha Gupta) - Avoid freeing decrypted memory in a confidential VM (Rick Edgecombe and Michael Kelley) * tag 'hyperv-fixes-signed-20240411' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted uio_hv_generic: Don't free decrypted memory hv_netvsc: Don't free decrypted memory Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails hv/hv_kvp_daemon: Handle IPv4 and Ipv6 combination for keyfile format hv: vmbus: Convert sprintf() family to sysfs_emit() family mshyperv: Introduce hv_numa_node_to_pxm_info() x86/hyperv: Cosmetic changes for hv_apic.c

uio_hv_generic: Don't free decrypted memory

2024-04-10T21:33:32Z

In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus device UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory. Signed-off-by: Rick Edgecombe Signed-off-by: Michael Kelley Reviewed-by: Kuppuswamy Sathyanarayanan Acked-by: Kirill A. Shutemov Link: https://lore.kernel.org/r/20240311161558.1310-5-mhklinux@outlook.com Signed-off-by: Wei Liu Message-ID: <20240311161558.1310-5-mhklinux@outlook.com>

Fix build errors due to new UIO_MEM_DMA_COHERENT mess

2024-03-27T16:48:47Z

Commit 576882ef5e7f ("uio: introduce UIO_MEM_DMA_COHERENT type") introduced a new use-case for 'struct uio_mem' where the 'mem' field now contains a kernel virtual address when 'memtype' is set to UIO_MEM_DMA_COHERENT. That in turn causes build errors, because 'mem' is of type 'phys_addr_t', and a virtual address is a pointer type. When the code just blindly uses cast to mix the two, it caused problems when phys_addr_t isn't the same size as a pointer - notably on 32-bit architectures with PHYS_ADDR_T_64BIT. The proper thing to do would probably be to use a union member, and not have any casts, and make the 'mem' member be a union of 'mem.physaddr' and 'mem.vaddr', based on 'memtype'. This is not that proper thing. This is just fixing the ugly casts to be even uglier, but at least not cause build errors on 32-bit platforms with 64-bit physical addresses. Reported-by: Guenter Roeck Fixes: 576882ef5e7f ("uio: introduce UIO_MEM_DMA_COHERENT type") Fixes: 7722151e4651 ("uio_pruss: UIO_MEM_DMA_COHERENT conversion") Fixes: 019947805a8d ("uio_dmem_genirq: UIO_MEM_DMA_COHERENT conversion") Cc: Greg Kroah-Hartman Cc: Chris Leech Cc: Nilesh Javali Cc: Christoph Hellwig Signed-off-by: Linus Torvalds

uio_dmem_genirq: UIO_MEM_DMA_COHERENT conversion

2024-03-07T21:52:59Z

Conversion of this driver to use UIO_MEM_DMA_COHERENT for dma_alloc_coherent memory instead of UIO_MEM_PHYS. Signed-off-by: Chris Leech Link: https://lore.kernel.org/r/20240205200257.138376-1-cleech@redhat.com Signed-off-by: Greg Kroah-Hartman

uio_pruss: UIO_MEM_DMA_COHERENT conversion

2024-03-07T21:52:59Z

Conversion of this driver to use UIO_MEM_DMA_COHERENT for dma_alloc_coherent memory instead of UIO_MEM_PHYS. Signed-off-by: Chris Leech Link: https://lore.kernel.org/r/20240201233400.3394996-4-cleech@redhat.com Signed-off-by: Greg Kroah-Hartman

uio: introduce UIO_MEM_DMA_COHERENT type

2024-03-07T21:52:59Z

Add a UIO memtype specifically for sharing dma_alloc_coherent memory with userspace, backed by dma_mmap_coherent. This is mainly for the bnx2/bnx2x/bnx2i "cnic" interface, although there are a few other uio drivers which map dma_alloc_coherent memory and will be converted to use dma_mmap_coherent as well. Signed-off-by: Nilesh Javali Signed-off-by: Chris Leech Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240205200137.138302-1-cleech@redhat.com Signed-off-by: Greg Kroah-Hartman

uio: Fix use-after-free in uio_open

2024-01-04T16:03:47Z

core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock. Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered") Cc: stable Signed-off-by: Guanghui Feng Reviewed-by: Baolin Wang Link: https://lore.kernel.org/r/1703152663-59949-1-git-send-email-guanghuifeng@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman

uio: pruss: fix missing iounmap() in pruss_probe()

2023-08-22T11:41:55Z

platform_get_irq() is called after ioremap(), if it fails, iounmap() needs be called in error the path. Fixes: 2fd84b9b839c ("uio: pruss: fix to check return value of platform_get_irq() in pruss_probe()") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20230808123827.560603-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman

uio: pruss: fix to check return value of platform_get_irq() in pruss_probe()

2023-08-04T14:21:04Z

The platform_get_irq might be failed and return a negative result. So there should have an error handling code. Fixed this by adding an error handling code. Signed-off-by: Zhang Shurong Link: https://lore.kernel.org/r/tencent_8E383752B54E5BF860711E500AD8A8971208@qq.com Signed-off-by: Greg Kroah-Hartman

uio: dfl: add vendor-specific feature id

2023-05-31T18:00:37Z

Add a Device Feature List (DFL) feature id as a generic mechanism to expose a vendor-specific FPGA IP to user space. The feature id is intended for use with IPs that do not need any kernel services beyond exposure to user space through the UIO DFL driver. The feature id is used in, e.g., Intel Oak Springs Canyon IPUs to expose various IPs to user space, e.g., Network Controller Sideband Interface (NC-SI), BaseNIC, and VirtIO management. Link: https://github.com/OPAE/dfl-feature-id Signed-off-by: Peter Colberg Signed-off-by: Matthew Gerlach Reviewed-by: Russ Weight Link: https://lore.kernel.org/r/20230531030737.12989-1-peter.colberg@intel.com Signed-off-by: Greg Kroah-Hartman