laptop-kernel/drivers/virt, branch master

Merge tag 'char-misc-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2026-10-03T16:05:47Z

Pull char/misc/IIO fixes from Greg KH: "Here is a set of char/misc/iio and other small driver subsystem fixes for 7.3-rc6 that resolve a number of reported issues. Included in here are: - lots of small iio driver fixes for reported problems - interconnect driver revert to resolve a regression - nitro_enclaves driver fix for a use-after-free - binder driver fixes for reported problems (in both the rust and C versions) All of these have been in linux-next with no reported issues" * tag 'char-misc-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (63 commits) iio: adc: ad_sigma_delta: fix use-after-free on unbind iio: accel: kxcjk-1013: reject duplicate event disable iio: buffer: serialize buffer teardown with mode claims iio: cdc: ad7150: fix OF matching and publish module aliases iio: adc: ade9000: fix NULL pointer dereference in clkout registration iio: adc: ad4030: fix invalid oversampling_ratio validation iio: adc: ad7173: Fix digital filter configuration iio: adc: stm32-adc: fix possible division by zero in processed channel iio: adc: stm32-adc: fix check on internal channel availability iio: proximity: isl29501: Fix return type of isl29501_register_write iio: imu: inv_icm42607: restore runtime PM on system resume errors iio: imu: inv_icm42607: propagate runtime suspend errors iio: adc: pac1934: check ACPI label duplication rust_binderfs: add transaction_report feature entry rust_binder: reschedule node refcount update on thread exit rust_binder: cancel deferred work items in thread exit binderfs: fix UAF write in binder_add_device binder: fix is_failure flag for superseded transaction cleanup binder: fix leaked fd fixups on TF_UPDATE_TXN supersede Revert "interconnect: qcom: x1e80100: enable QoS configuration" ...

virt: vmgenid: move to using dev_set/get_drvdata

2026-09-16T09:48:06Z

The prior commit moved the order of initializing driver_data around. In looking through the tree at what is normally done, it appears that actually few drivers set or get driver_data directly, but instead go through the dev_set/get_drvdata helpers, which are simple inline helpers that amount to the same exact code. So, for the sake of consistency, use the helpers. Signed-off-by: Jason A. Donenfeld

nitro_enclaves: fix use-after-free on SLOT_ALLOC failure

2026-09-09T12:56:26Z

When ne_create_vm_ioctl() fails the SLOT_ALLOC request after anon_inode_getfile() has succeeded, the error path calls fput(enclave_file) and then frees ne_enclave. In normal userspace context, fput() defers the final __fput() via task_work. ne_enclave_release() therefore runs after ne_enclave has already been freed and dereferences ne_enclave->slot_uid, causing a use-after-free: KASAN: slab-use-after-free in ne_enclave_release. The enclave has no slot allocated and is not yet linked into the enclaves list on this error path, so ne_enclave_release() is expected to return early when slot_uid is zero. However, reading slot_uid already accesses the freed object. Clear enclave_file->private_data before fput() on the error path. ne_enclave_release() then returns immediately when private_data is NULL, leaving the ioctl error path as the sole owner of ne_enclave. This is safe because the file has not been fd_install()'d yet. Tested on an AWS EC2 m5.2xlarge with CONFIG_KASAN=y. Without the patch, the reproducer triggers a KASAN slab-use-after-free on every SLOT_ALLOC failure. With the patch, no KASAN report is produced and the SLOT_ALLOC error is still returned. Normal enclave creation and teardown are unaffected. Fixes: 9c8eb50fe9e2 ("nitro_enclaves: Add logic for terminating an enclave") Cc: stable@vger.kernel.org Co-developed-by: Zhaofeng Chen Signed-off-by: Zhaofeng Chen Signed-off-by: Yuxiao Wang Reviewed-by: Alexander Graf Link: https://patch.msgid.link/20260909124400.27857-1-graf@amazon.com Signed-off-by: Greg Kroah-Hartman

virt: vmgenid: set driver_data before registering notification handlers

2026-08-31T03:36:21Z

Both probe paths register their notification handler before assigning driver_data, which the handler dereferences. In the devicetree path, the notification IRQ can fire as soon as devm_request_irq() registers the handler: the interrupt may already be pending at probe time, for example when a VMM injects the generation-changed notification while restoring a guest from a snapshot that was taken before the driver had probed (Firecracker does exactly this on snapshot restore). The IRQ is also requested with IRQF_SHARED, so another device sharing the line can trigger the handler just as early. The handler then calls vmgenid_notify(), which dereferences the still-NULL driver_data and panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none) Hardware name: linux,dummy-virt (DT) pc : vmgenid_notify.isra.0+0x24/0x8c lr : vmgenid_of_irq_handler+0x14/0x34 Call trace: vmgenid_notify.isra.0+0x24/0x8c (P) vmgenid_of_irq_handler+0x14/0x34 __handle_irq_event_percpu+0x44/0x1bc handle_irq_event+0x4c/0xb4 handle_fasteoi_irq+0xf8/0x1f8 The ACPI path has the same ordering problem: the handler is installed with acpi_install_notify_handler() before driver_data is assigned. ACPI notifications are dispatched asynchronously from a workqueue, so the window is narrow, but a notification arriving between the two calls hits the same NULL dereference. Assign driver_data before registering the handlers. The state is fully initialized at that point, so the handlers are safe to run. Should registration fail, the probe error path leaves no dangling pointer behind: the driver core clears driver_data in device_unbind_cleanup(). Fixes: 7b1bcd6b50a6 ("virt: vmgenid: add support for devicetree bindings") Fixes: e07606713a90 ("virt: vmgenid: change implementation to use a platform driver") Cc: stable@vger.kernel.org Signed-off-by: Zhichen Wang Signed-off-by: Jason A. Donenfeld

virt: vmgenid: remap memory as decrypted

2026-08-31T03:32:34Z

It was found that AWS SEV-SNP enabled instances are not able to boot with commit 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default") applied and the reason seems to be the vmgenid device which requires unencrypted writeable memory. A similar problem was previously fixed in DRM with commit 7dfede7d7edd ("drm/vmwgfx: Fix guests running with TDX/SEV"). Note, trusting vmgenid device in a Confidential VM is questionable: the malicious host may intentionally avoid notifying the guest when a copy is created. Fixes: 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default") Signed-off-by: Vitaly Kuznetsov Cc: stable@vger.kernel.org # 6.15+ Signed-off-by: Jason A. Donenfeld

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2026-08-18T18:57:17Z

Pull arm64 updates from Will Deacon: "There's a reasonable amount of stuff here, including a bunch of updates to the perf PMU drivers and some MPAM updates to expose the memory bandwidth counters via resctrl. On the architecture side, some highlights include support for BBML3 and steps towards support for an architectural NMI solution, all wrapped up in a web of fixes for latent issues identified by Sashiko. ACPI: - Combine reads of AMU counters into a single FFH feedback counter op Confidential computing: - Fix smp_processor_id() in preemptible context when retrieving an attestation token inside a realm - Convert pKVM over to a "CC platform" - Clean-up our SWIOTLB configuration in preparation for reworking the handling of encrypted/decryped DMA buffers in the dma-mapping tree CPU errata handling: - Work around broken device memory ordering on NVIDIA Olympus cores - Fix broken 'nospectre_bhb' command-line option - Select the idle loop backend instruction on the command-line CPU features: - Replace our BBML2-noabort feature with the new architectural BBML3 feature - Disable in-kernel BTI for recent versions of Clang due to issues with livepatch that are still being investigated - Clean-up documentation describing which ID register fields are exposed to userspace Interrupts: - Preliminary work towards supporting FEAT_NMI, which cleans up our IRQ entry code and fixes some latent issues with pseudo-NMI - Support for an SDEI backend to trigger an NMI backtrace Memory management: - Treat all devices as coherent when CLIDR_EL1.LoC == 0 - Fix no-map handling of sub-page-sized regions - Second attempt at unmapping the linear aliases of the kernel data and bss sections - Fix EFI runtime calls when software-PAN is enabled Miscellaneous: - Add Mark Rutland as a reviewer! - Tidy-up our futex cmpxchg logic when using the new LSUI instructions - Drop the requirement on DYNAMIC_FTRACE_WITH_CALL_OPS when selecting HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS - Fix a false-positive KCSCAN splat in the delay loop - Use a portable typedef for 128-bit scalar types in our UAPI headers - Non-critical fixes for Sashiko reports all over MPAM: - Hook MPAM memory bandwidth counters into resctrl's counter assignment interface - Fix a quirk in the MPAM bandwidth counting on Nvidia T241 so that it also applies to 63 bit counters Perf: - Workarounds for hardware issues in the CMN-S3 PMU (Graviton 5) and CPU PMU (NVIDIA Olympus again!) - Add support for the DDR PMU on Marvell CN20K SoCs - Add support for Picoheart implementations of the DCW PCIe PMU - Add support for Channel/Rank/Bank filtering in the CXL PMU driver - Add support for 64-bit counters in the CSPMU device - Add support for revision 2 of the CMN S3 PMU Ptrace: - Fix a decade-old bug in our handling of seccomp and tracing on syscall entry - Fix regset handling for inactive SVE and SSVE registers Selftests - Add some tests for the decade-old bug that we just tried to fix in our syscall entry path - Fix SVE test crash on SME-only CPUs" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (95 commits) arm64/efi: Avoid voluntary preemption with efi_mm installed arm64: bti: Disable in-kernel BTI with recent versions of Clang arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit irqchip/gic-v3: make the unmasking of pseudo-NMIs explicit when handling IRQs arm64: Disable KCSAN instrumentation in delay.o arm_mpam: Disable driver unbind to avoid UAF arm_mpam: Fix a NULL pointer dereference on unbinding after an error interrupt perf: arm_pmuv3: Zero initialize hw_id branch stack field arm64: mm: Unmap kernel data/bss entirely from the linear map iommu/arm-smmu-v3-sva: Use system_supports_bbml3() to detect CPU feature perf/arm-cmn: Support CMN S3 r2 perf/arm-cmn: Plumb in new filter types perf/arm-cmn: Refactor event filter data perf/arm-cmn: Refactor event filter programming perf/arm-cmn: Rename filter variables for clarity arm64: mm: fix accidental linear mapping of no-map reserved memory tools: Ensure tools copy of linux/filter.h exports the UAPI kselftest/arm64: Fix abi test compilation errors arch: arm64: add early_param idle= arm64: entry: mask DAIF before returning from C EL1 handlers ...

Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

2026-08-18T02:16:42Z

Pull crypto library updates from Eric Biggers: "Add library APIs for most AES encryption modes that are used in the kernel (ECB, CBC, CBC-CTS, CTR, XCTR, XTS, GCM, CCM). These AES modes have many in-kernel users that are currently using the crypto_skcipher or crypto_aead APIs. These existing APIs are difficult to use and inefficient. Until now, the lack of proper library support for these has been the main gap in the crypto library. This set of changes is the next stage of addressing it: - Implement the new APIs on top of the existing support for single-block AES in the library. - Fully document the new APIs. - Migrate the only user of the old AES-GCM library API to the new, more flexible API; then remove the old API and its implementation. - Wire up the new APIs to the traditional crypto API by adding crypto_skcipher and crypto_aead algorithms. This makes the new APIs be covered by the traditional crypto API's self-tests. It also makes them be already used for real on systems that don't have architecture-optimized code for these modes. But most importantly, this is a prerequisite for migrating the architecture-optimized code for these AES modes (i.e. arch/*/crypto/aes*) into the library, which as usual will eliminate a lot of redundant "glue" code. Note that unlike some of the other algorithms that have been migrated to the library, e.g. SHA-512, for these AES modes there was too much to get done in one cycle. Nor did it make sense to handle these modes one at a time, because they tend to be coupled together or depend on each other, especially in the architecture-optimized AES code. Thus, most of the benefits (reductions in lines of code, performance improvements, etc.) will follow in later cycles when architecture-optimized code is migrated into the library and users of crypto_skcipher and crypto_aead are updated to use the new APIs. The design of the new APIs was informed by writing proof-of-concept patches for many kernel subsystems currently accessing these same algorithms via crypto_skcipher or crypto_aead (patches 18-33 of https://lore.kernel.org/r/20260707053503.209874-1-ebiggers@kernel.org/). While those patches will be resent for real later, the total diffstat for them was negative 1905 lines. So clearly the new APIs are quite a bit easier to use and align better with what users actually need. Besides the new AES encryption APIs, there are also a few changes for improved AES-CMAC key and context zeroization" * tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: mac80211: fils_aead: Use __cleanup() instead of memzero_explicit() Bluetooth: SMP: clear the aes_cmac_key when done smb: clear the aes_cmac_key and aes_cmac_ctx when done lib/crypto: aes-cmac: Add zeroization functions lib/crypto: aesgcm: Remove old AES-GCM library x86/sev: Remove obsolete virtual address check x86/sev: Use new AES-GCM library crypto: aes - Add CCM support using library crypto: aes - Add GCM support using library crypto: aes - Add XTS support using library crypto: aes - Add CTR and XCTR support using library crypto: aes - Add CBC and CBC-CTS support using library crypto: aes - Add ECB support using library lib/crypto: aes: Add CCM support lib/crypto: aes: Add GCM support lib/crypto: aes: Add XTS support lib/crypto: aes: Add CTR and XCTR support lib/crypto: aes: Add CBC and CBC-CTS support lib/crypto: aes: Add ECB support crypto: xts - Split out __xts_verify_key() helper

x86/sev: Use new AES-GCM library

2026-07-23T16:30:29Z

The old AES-GCM library code is being replaced as part of an overhaul that is adding support for all the common AES encryption modes with consistent conventions. The SEV code is the only user of the old AES-GCM library. Update it to use the new API instead. Besides adjustments to the key struct name, function names, return value, and parameter order, the only notable changes are: - Replace the direct accesses to the auth tag length field (which should be considered private until someone truly needs it) with the AUTHTAG_LEN constant which is already defined in . - Replace kfree() with kfree_sensitive() on lines being changed anyway. Tested-by: Nikunj A Dadhania Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260722025338.33354-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

virt: arm-cca-guest: Drop unused assignment of platform_device_id driver data

2026-07-22T20:19:45Z

The driver explicitly sets the .driver_data member of struct platform_device_id to zero without relying on that value. Drop this unused assignment. While touching this array use a named initializer for .name. Signed-off-by: Uwe Kleine-König (The Capable Hub) Signed-off-by: Will Deacon

arm64/coco: Add pKVM as a CC platform

2026-07-21T22:27:47Z

pKVM does support memory encryption, expose that to the rest of the kernel through cc_platform_has() At the moment, all devices inside the guest are emulated which requires its memory to be shared back to the host (decrypted), so set force_dma_unencrypted() to always return true. Although, typically pKVM guests rely on restricted-dma-pools to bounce traffic, with this change, it is possible to solely rely on the default SWIOTLB for that (assuming the appropriate size is set from the command line) Signed-off-by: Mostafa Saleh Reviewed-by: Catalin Marinas Tested-by: Aneesh Kumar K.V (Arm) Signed-off-by: Will Deacon