kernel/drivers/firmware, branch linux-rolling-stable

firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled

2026-03-19T15:15:10Z

commit c45f7263100cece247dd3fa5fe277bd97fdb5687 upstream. When the Remote System Update (RSU) isn't enabled in the First Stage Boot Loader (FSBL), the driver encounters a NULL pointer dereference when excute svc_normal_to_secure_thread() thread, resulting in a kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ... Data abort info: ... [0000000000000008] user address but active_mm is swapper Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 79 Comm: svc_smc_hvc_thr Not tainted 6.19.0-rc8-yocto-standard+ #59 PREEMPT Hardware name: SoCFPGA Stratix 10 SoCDK (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : svc_normal_to_secure_thread+0x38c/0x990 lr : svc_normal_to_secure_thread+0x144/0x990 ... Call trace: svc_normal_to_secure_thread+0x38c/0x990 (P) kthread+0x150/0x210 ret_from_fork+0x10/0x20 Code: 97cfc113 f9400260 aa1403e1 f9400400 (f9400402) ---[ end trace 0000000000000000 ]--- The issue occurs because rsu_send_async_msg() fails when RSU is not enabled in firmware, causing the channel to be freed via stratix10_svc_free_channel(). However, the probe function continues execution and registers svc_normal_to_secure_thread(), which subsequently attempts to access the already-freed channel, triggering the NULL pointer dereference. Fix this by properly cleaning up the async client and returning early on failure, preventing the thread from being used with an invalid channel. Fixes: 15847537b623 ("firmware: stratix10-rsu: Migrate RSU driver to use stratix10 asynchronous framework.") Cc: stable@kernel.org Signed-off-by: Liwei Song Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman

firmware: cs_dsp: Fix fragmentation regression in firmware download

2026-03-19T15:14:51Z

[ Upstream commit facfdef64d11c08e6f1e69d02a0b87cb74cee0f5 ] Use vmalloc() instead of kmalloc(..., GFP_DMA) to alloc the temporary buffer for firmware download blobs. This avoids the problem that a heavily fragmented system cannot allocate enough physically-contiguous memory for a large blob. The redundant alloc buffer mechanism was removed in commit 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator"). While doing that I was overly focused on the possibility of the underlying bus requiring DMA-safe memory. So I used GFP_DMA kmalloc()s. I failed to notice that the code I was removing used vmalloc(). This creates a regression. Way back in 2014 the problem of fragmentation with kmalloc()s was fixed by commit cdcd7f728753 ("ASoC: wm_adsp: Use vmalloc to allocate firmware download buffer"). Although we don't need physically-contiguous memory, we don't know if the bus needs some particular alignment of the buffers. Since the change in 2014, the firmware download has always used whatever alignment vmalloc() returns. To avoid introducing a new problem, the temporary buffer is still used, to keep the same alignment of pointers passed to regmap_raw_write(). Signed-off-by: Richard Fitzgerald Fixes: 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator") Link: https://patch.msgid.link/20260304141250.1578597-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

x86/efi: defer freeing of boot services memory

2026-03-12T11:09:30Z

commit a4b0bf6a40f3c107c67a24fbc614510ef5719980 upstream. efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete. Link: https://lore.kernel.org/all/ec2aaef14783869b3be6e3c253b2dcbf67dbc12a.camel@kernel.crashing.org Fixes: 916f676f8dc0 ("x86, efi: Retain boot service code until after switching to virtual mode") Cc: Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Benjamin Herrenschmidt Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

firmware: arm_ffa: Unmap Rx/Tx buffers on init failure

2026-03-04T12:19:46Z

[ Upstream commit 9fda364cb78c8b9e1abe4029f877300c94655742 ] ffa_init() maps the Rx/Tx buffers via ffa_rxtx_map() but on the partition setup failure path it never unmaps them. Add the missing ffa_rxtx_unmap() call in the error path so that the Rx/Tx buffers are properly released before freeing the backing pages. Signed-off-by: Haoxiang Li Message-Id: <20251210031656.56194-1-lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

EFI/CPER: don't go past the ARM processor CPER record buffer

2026-03-04T12:19:37Z

[ Upstream commit eae21beecb95a3b69ee5c38a659f774e171d730e ] There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198 Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/41cd9f6b3ace3cdff7a5e864890849e4b1c58b63.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

EFI/CPER: don't dump the entire memory region

2026-03-04T12:19:37Z

[ Upstream commit 55cc6fe5716f678f06bcb95140882dfa684464ec ] The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/1752b5ba63a3e2f148ddee813b36c996cc617e86.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

efi: Fix reservation of unaccepted memory table

2026-02-26T23:01:37Z

[ Upstream commit 0862438c90487e79822d5647f854977d50381505 ] The reserve_unaccepted() function incorrectly calculates the size of the memblock reservation for the unaccepted memory table. It aligns the size of the table, but fails to account for cases where the table's starting physical address (efi.unaccepted) is not page-aligned. If the table starts at an offset within a page and its end crosses into a subsequent page that the aligned size does not cover, the end of the table will not be reserved. This can lead to the table being overwritten or inaccessible, causing a kernel panic in accept_memory(). This issue was observed when starting Intel TDX VMs with specific memory sizes (e.g., > 64GB). Fix this by calculating the end address first (including the unaligned start) and then aligning it up, ensuring the entire range is covered by the reservation. Fixes: 8dbe33956d96 ("efi/unaccepted: Make sure unaccepted table is mapped") Reported-by: Moritz Sanft Signed-off-by: Kiryl Shutsemau (Meta) Reviewed-by: Tom Lendacky Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

firmware: cs_dsp: Don't use __free() in cs_dsp_load() and cs_dsp_load_coeff()

2026-02-26T23:00:55Z

[ Upstream commit ae9ccaed3f6701ee0fe40ad919516e0aa0844f21 ] Replace the __free(kfree) in cs_dsp_load() and cs_dsp_load_coeff() with a kfree(buf) at the end of the function. The use of __free() can create new cleanup bugs that are difficult to spot because the defective code is idiomatically correct regular C. In these two functions the __free() was mixed with gotos, and also used the suspect declaration __free(kfree) = NULL;. The __free() did not do anything to simplify the code. There aren't any early returns after the pointer is set, and the __free() can be replaced by a kfree() at the end of the function. Signed-off-by: Richard Fitzgerald Fixes: 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator") Link: https://patch.msgid.link/20251201160729.231867-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

firmware: cs_dsp: Remove __free() from cs_dsp_debugfs_string_read()

2026-02-26T23:00:55Z

[ Upstream commit 7a9fa7fda93b7b3ae515f40f67bbf8e1d16337e8 ] Don't use __free(kfree) in cs_dsp_debugfs_string_read. Instead use normal kfree() to cleanup. The use of __free() can create new cleanup bugs that are difficult to spot because the defective code is idiomatically correct regular C. This function used the suspect declaration __free(kfree) = NULL;. The __free(kfree) didn't really do anything here. The function can be rearranged to avoid any need to return or goto within the code. Signed-off-by: Richard Fitzgerald Fixes: 3045e29d248b ("firmware: cs_dsp: Append \n to debugfs string during read") Link: https://patch.msgid.link/20251202113425.413700-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET

2026-02-26T23:00:50Z

[ Upstream commit be4d4543f78074fbebd530ba5109d39a2a34e668 ] The FF-A specification allows NOTIFICATION_INFO_GET to return either a 64-bit (FFA_FN64_SUCCESS) or a 32-bit (FFA_SUCCESS) response, depending on whether the firmware chooses the SMC64 or SMC32 calling convention. The driver previously detected the response format by checking ret.a0, but still interpreted the returned ID lists (x3..x17 or w3..w7) as if they always followed the 64-bit SMC64 layout. In the SMC32 case, the upper 32 bits of each argument register are undefined by the calling convention, meaning the driver could read stale or garbage values when parsing notification IDs. This resulted in incorrectly decoded partition/VCPU IDs whenever the FF-A firmware used an SMC32 return path. Fix the issue by: - Introducing logic to map list indices to the correct u16 offsets, depending on whether the response width matches the kernel word size or is a 32-bit response on a 64-bit kernel. - Ensuring that the packed ID list is parsed using the proper layout, avoiding reads from undefined upper halves in the SMC32 case. With this change, NOTIFICATION_INFO_GET now correctly interprets ID list entries regardless of the response width, aligning the driver with the FF-A specification. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Sourav Mohapatra Message-Id: <20251218142001.2457111-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin