linux-stable.git/drivers/misc, branch linux-6.17.y

misc: rp1: Fix an error handling path in rp1_probe()

2025-12-18T12:59:58+00:00

[ Upstream commit 43cd4b634ef90c4e2ff75eaeb361786fa04c8874 ]

When DT is used to get the reference of 'rp1_node', it should be released
when not needed anymore, otherwise it is leaking.

In such a case, add the missing of_node_put() call at the end of the probe,
as already done in the error handling path.

Fixes: 49d63971f963 ("misc: rp1: RaspberryPi RP1 misc driver")
Signed-off-by: Christophe JAILLET 
Reviewed-by: Andrea della Porta 
Link: https://patch.msgid.link/9bc1206de787fa86384f3e5ba0a8027947bc00ff.1762585959.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mei: make a local copy of client uuid in connect

2025-11-13T20:37:27+00:00

[ Upstream commit bb29fc32ae56393269d8fe775159fd59e45682d1 ]

Connect ioctl has the same memory for in and out parameters.
Copy in parameter (client uuid) to the local stack to avoid it be
overwritten by out parameters fill.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/20250918130435.3327400-3-alexander.usyskin@intel.com
Signed-off-by: Sasha Levin

eeprom: at25: support Cypress FRAMs without device ID

2025-11-13T20:37:16+00:00

[ Upstream commit 1b434ed000cd474f074e62e8ab876f87449bb4ac ]

Not all FRAM chips have a device ID and implement the corresponding read
command. For such chips this led to the following error on module
loading:

    at25 spi2.0: Error: no Cypress FRAM (id 00)

The device ID contains the memory size, so devices without this ID are
supported now by setting the size manually in Devicetree using the
"size" property.

Tested with FM25L16B and "size = <2048>;":

    at25 spi2.0: 2 KByte fm25 fram, pagesize 4096

According to Infineon/Cypress datasheets, these FRAMs have a device ID:

    FM25V01A
    FM25V02A
    FM25V05
    FM25V10
    FM25V20A
    FM25VN10

but these do not:

    FM25040B
    FM25640B
    FM25C160B
    FM25CL64B
    FM25L04B
    FM25L16B
    FM25W256

So all "FM25V*" FRAMs and only these have a device ID. The letter after
"FM25" (V/C/L/W) only describes the voltage range, though.

Link: https://lore.kernel.org/all/20250401133148.38330-1-m.heidelberg@cab.de/
Signed-off-by: Markus Heidelberg 
Reviewed-by: Alexander Sverdlin 
Link: https://lore.kernel.org/r/20250815095839.4219-3-m.heidelberg@cab.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

misc: pci_endpoint_test: Skip IRQ tests if irq is out of range

2025-11-13T20:37:07+00:00

[ Upstream commit cc8e391067164f45f89b6132a5aaa18c33a0e32b ]

The pci_endpoint_test tests the 32-bit MSI range. However, the device might
not have all vectors configured. For example, if msi_interrupts is 8 in the
ep function space or if the MSI Multiple Message Capable value is
configured as 4 (maximum 16 vectors).

In this case, do not attempt to run the test to avoid timeouts and directly
return the error value.

Signed-off-by: Christian Bruel 
Signed-off-by: Manivannan Sadhasivam 
Link: https://patch.msgid.link/20250804170916.3212221-2-christian.bruel@foss.st.com
Signed-off-by: Sasha Levin

vmw_balloon: indicate success when effectively deflating during migration

2025-10-29T13:10:32+00:00

[ Upstream commit 4ba5a8a7faa647ada8eae61a36517cf369f5bbe4 ]

When migrating a balloon page, we first deflate the old page to then
inflate the new page.

However, if inflating the new page succeeded, we effectively deflated the
old page, reducing the balloon size.

In that case, the migration actually worked: similar to migrating+
immediately deflating the new page.  The old page will be freed back to
the buddy.

Right now, the core will leave the page be marked as isolated (as we
returned an error).  When later trying to putback that page, we will run
into the WARN_ON_ONCE() in balloon_page_putback().

That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction:
stop using __ClearPageMovable()"); before that change, we would have
tolerated that way of handling it.

To fix it, let's just return 0 in that case, making the core effectively
just clear the "isolated" flag + freeing it back to the buddy as if the
migration succeeded.  Note that the new page will also get freed when the
core puts the last reference.

Note that this also makes it all be more consistent: we will no longer
unisolate the page in the balloon driver while keeping it marked as being
isolated in migration core.

This was found by code inspection.

Link: https://lkml.kernel.org/r/20251014124455.478345-1-david@redhat.com
Fixes: 3544c4faccb8 ("mm/balloon_compaction: stop using __ClearPageMovable()")
Signed-off-by: David Hildenbrand 
Cc: Jerrin Shaji George 
Cc: Broadcom internal kernel review list 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

treewide: remove MIGRATEPAGE_SUCCESS

2025-10-29T13:10:32+00:00

[ Upstream commit fb49a4425cfa163faccd91f913773d3401d3a7d4 ]

At this point MIGRATEPAGE_SUCCESS is misnamed for all folio users,
and now that we remove MIGRATEPAGE_UNMAP, it's really the only "success"
return value that the code uses and expects.

Let's just get rid of MIGRATEPAGE_SUCCESS completely and just use "0"
for success.

Link: https://lkml.kernel.org/r/20250811143949.1117439-3-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Zi Yan 			[mm]
Acked-by: Dave Kleikamp 	[jfs]
Acked-by: David Sterba 		[btrfs]
Acked-by: Greg Kroah-Hartman 
Reviewed-by: Byungchul Park 
Cc: Alistair Popple 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Benjamin LaHaise 
Cc: Chris Mason 
Cc: Christian Brauner 
Cc: Christophe Leroy 
Cc: Dave Kleikamp 
Cc: Eugenio Pé rez 
Cc: Gregory Price 
Cc: "Huang, Ying" 
Cc: Jan Kara 
Cc: Jason Wang 
Cc: Jerrin Shaji George 
Cc: Josef Bacik 
Cc: Joshua Hahn 
Cc: Madhavan Srinivasan 
Cc: Mathew Brost 
Cc: Michael Ellerman 
Cc: "Michael S. Tsirkin" 
Cc: Minchan Kim 
Cc: Muchun Song 
Cc: Nicholas Piggin 
Cc: Oscar Salvador 
Cc: Rakie Kim 
Cc: Sergey Senozhatsky 
Cc: Xuan Zhuo 
Cc: Lance Yang 
Signed-off-by: Andrew Morton 
Stable-dep-of: 4ba5a8a7faa6 ("vmw_balloon: indicate success when effectively deflating during migration")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup

2025-10-29T13:10:30+00:00

commit fff111bf45cbeeb659324316d68554e35d350092 upstream.

In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to
the dma_buf for comparison purposes. However, this reference is never
released when the function returns, leading to a dma_buf memory leak.

Fix this by adding dma_buf_put before returning from the function,
ensuring that the temporarily acquired reference is properly released
regardless of whether a matching map is found.

Fixes: 9031626ade38 ("misc: fastrpc: Fix fastrpc_map_lookup operation")
Cc: stable@kernel.org
Signed-off-by: Junhao Xie 
Tested-by: Xilin Wu 
Link: https://lore.kernel.org/stable/48B368FB4C7007A7%2B20251017083906.3259343-1-bigfoot%40radxa.com
Link: https://patch.msgid.link/48B368FB4C7007A7+20251017083906.3259343-1-bigfoot@radxa.com
Signed-off-by: Greg Kroah-Hartman

mei: me: add wildcat lake P DID

2025-10-29T13:10:30+00:00

commit 410d6c2ad4d1a88efa0acbb9966693725b564933 upstream.

Add Wildcat Lake P device id.

Cc: stable@vger.kernel.org
Co-developed-by: Tomas Winkler 
Signed-off-by: Tomas Winkler 
Signed-off-by: Alexander Usyskin 
Link: https://patch.msgid.link/20251016125912.2146136-1-alexander.usyskin@intel.com
Signed-off-by: Greg Kroah-Hartman

lkdtm: fortify: Fix potential NULL dereference on kmalloc failure

2025-10-29T13:10:16+00:00

[ Upstream commit 01c7344e21c2140e72282d9d16d79a61f840fc20 ]

Add missing NULL pointer checks after kmalloc() calls in
lkdtm_FORTIFY_STR_MEMBER() and lkdtm_FORTIFY_MEM_MEMBER() functions.

Signed-off-by: Junjie Cao 
Link: https://lore.kernel.org/r/20250814060605.5264-1-junjie.cao@intel.com
Signed-off-by: Kees Cook 
Signed-off-by: Sasha Levin

misc: fastrpc: Skip reference for DMA handles

2025-10-15T10:04:21+00:00

commit 10df039834f84a297c72ec962c0f9b7c8c5ca31a upstream.

If multiple dma handles are passed with same fd over a remote call
the kernel driver takes a reference and expects that put for the
map will be called as many times to free the map. But DSP only
updates the fd one time in the fd list when the DSP refcount
goes to zero and hence kernel make put call only once for the
fd. This can cause SMMU fault issue as the same fd can be used
in future for some other call.

Fixes: 35a82b87135d ("misc: fastrpc: Add dma handle implementation")
Cc: stable@kernel.org
Co-developed-by: Ekansh Gupta 
Signed-off-by: Ekansh Gupta 
Signed-off-by: Ling Xu 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20250912131236.303102-5-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman