From ab99eaafb0c4b412cfeb895a8cf091626e2bbd86 Mon Sep 17 00:00:00 2001 From: Ekansh Gupta Date: Fri, 24 Jul 2026 23:33:37 +0100 Subject: [PATCH 01/15] misc: fastrpc: Fix initial memory allocation for Audio PD memory pool The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Ekansh Gupta Signed-off-by: Jianping Li Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/misc/fastrpc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index f3a49384586d..4f01ebfa6f95 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -1370,7 +1370,9 @@ static int fastrpc_init_create_static_process(struct fastrpc_user *fl, err = PTR_ERR(name); goto err; } - + inbuf.client_id = fl->client_id; + inbuf.namelen = init.namelen; + inbuf.pageslen = 0; if (!fl->cctx->remote_heap) { err = fastrpc_remote_heap_alloc(fl, fl->sctx->dev, init.memlen, &fl->cctx->remote_heap); @@ -1393,12 +1395,10 @@ static int fastrpc_init_create_static_process(struct fastrpc_user *fl, goto err_map; } scm_done = true; + inbuf.pageslen = 1; } } - inbuf.client_id = fl->client_id; - inbuf.namelen = init.namelen; - inbuf.pageslen = 0; fl->pd = USER_PD; args[0].ptr = (u64)(uintptr_t)&inbuf; From 6102ceb4eab845743ee57acd3863fbd06e93c927 Mon Sep 17 00:00:00 2001 From: Ekansh Gupta Date: Fri, 24 Jul 2026 23:33:38 +0100 Subject: [PATCH 02/15] misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list. Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Ekansh Gupta Signed-off-by: Jianping Li Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/misc/fastrpc.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 4f01ebfa6f95..12dcd2e737c3 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -1889,9 +1889,6 @@ static int fastrpc_req_munmap_impl(struct fastrpc_user *fl, struct fastrpc_buf * &args[0]); if (!err) { dev_dbg(dev, "unmmap\tpt 0x%09lx OK\n", buf->raddr); - spin_lock(&fl->lock); - list_del(&buf->node); - spin_unlock(&fl->lock); fastrpc_buf_free(buf); } else { dev_err(dev, "unmmap\tpt 0x%09lx ERROR\n", buf->raddr); @@ -1905,6 +1902,7 @@ static int fastrpc_req_munmap(struct fastrpc_user *fl, char __user *argp) struct fastrpc_buf *buf = NULL, *iter, *b; struct fastrpc_req_munmap req; struct device *dev = fl->sctx->dev; + int err; if (copy_from_user(&req, argp, sizeof(req))) return -EFAULT; @@ -1912,6 +1910,7 @@ static int fastrpc_req_munmap(struct fastrpc_user *fl, char __user *argp) spin_lock(&fl->lock); list_for_each_entry_safe(iter, b, &fl->mmaps, node) { if ((iter->raddr == req.vaddrout) && (iter->size == req.size)) { + list_del(&iter->node); buf = iter; break; } @@ -1924,7 +1923,14 @@ static int fastrpc_req_munmap(struct fastrpc_user *fl, char __user *argp) return -EINVAL; } - return fastrpc_req_munmap_impl(fl, buf); + err = fastrpc_req_munmap_impl(fl, buf); + if (err) { + spin_lock(&fl->lock); + list_add_tail(&buf->node, &fl->mmaps); + spin_unlock(&fl->lock); + } + + return err; } static int fastrpc_req_mmap(struct fastrpc_user *fl, char __user *argp) From b85a0e91d7d6cd06a53c881a46f749cfcef416a2 Mon Sep 17 00:00:00 2001 From: Junrui Luo Date: Fri, 24 Jul 2026 23:33:39 +0100 Subject: [PATCH 03/15] misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor. Fixes: 76e8e4ace1ed ("misc: fastrpc: Safekeep mmaps on interrupted invoke") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/misc/fastrpc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 12dcd2e737c3..c75eafe872cc 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -1305,10 +1305,12 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, } if (err == -ERESTARTSYS) { + spin_lock(&fl->lock); list_for_each_entry_safe(buf, b, &fl->mmaps, node) { list_del(&buf->node); list_add_tail(&buf->node, &fl->cctx->invoke_interrupted_mmaps); } + spin_unlock(&fl->lock); } if (err) From 310f7868399668c6d99d88acc9c4cf3462e69d5b Mon Sep 17 00:00:00 2001 From: Anandu Krishnan E Date: Fri, 24 Jul 2026 23:33:40 +0100 Subject: [PATCH 04/15] misc: fastrpc: fix channel ctx ref leak when session alloc fails fastrpc_channel_ctx_get() is called in fastrpc_device_open() before fastrpc_session_alloc(). If session alloc fails, the error path returns -EBUSY without calling fastrpc_channel_ctx_put(), leaking the reference. Fix by adding the missing put. Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context") Cc: stable@kernel.org Signed-off-by: Anandu Krishnan E Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/misc/fastrpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index c75eafe872cc..f8cbe30c5d5c 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -1675,7 +1675,7 @@ static int fastrpc_device_open(struct inode *inode, struct file *filp) dev_err(&cctx->rpdev->dev, "No session available\n"); mutex_destroy(&fl->mutex); kfree(fl); - + fastrpc_channel_ctx_put(cctx); return -EBUSY; } From 2fae94ee14f7fea11d3f95e10383a87c01d21518 Mon Sep 17 00:00:00 2001 From: Eddie Lin Date: Fri, 24 Jul 2026 23:33:41 +0100 Subject: [PATCH 05/15] misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free The 'ctx_idr' is initialized but never destroyed when the channel context is freed, leading to a memory leak. Add idr_destroy() to properly clean up the IDR resources. Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model") Cc: stable@vger.kernel.org Signed-off-by: Eddie Lin Reviewed-by: Ekansh Gupta Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223342.629168-6-srini@kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/misc/fastrpc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index f8cbe30c5d5c..eb6c2a78d3c7 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -492,6 +492,7 @@ static void fastrpc_channel_ctx_free(struct kref *ref) cctx = container_of(ref, struct fastrpc_channel_ctx, refcount); + idr_destroy(&cctx->ctx_idr); kfree(cctx); } From ff10b6db0ab75b132aed69ab144ac04f63ef9bdb Mon Sep 17 00:00:00 2001 From: Aelin Reidel Date: Fri, 24 Jul 2026 23:34:03 +0100 Subject: [PATCH 06/15] nvmem: apple-spmi-nvmem: wrap regmap calls to satisfy CFI The Apple SPMI NVMEM driver previously cast regmap_bulk_read/write to void * when assigning them to nvmem_config's reg_read/reg_write function pointers. This cast breaks the expected function signature of nvmem_reg_read_t and nvmem_reg_write_t. With CFI enabled, indirect calls through these pointers fail: CFI failure at nvmem_reg_write+0x194/0x1e4 (target: regmap_bulk_write+0x0/0x2c8; expected type: 0x83a189c3) ... Call trace: nvmem_reg_write+0x194/0x1e4 (P) __nvmem_cell_entry_write+0x298/0x2e8 nvmem_cell_write+0x24/0x34 macsmc_reboot_probe+0x1dc/0x454 [macsmc_reboot] ... Introduce thin wrapper functions with the correct nvmem function pointer types to satisfy the CFI checks. Fixes: fe91c24a551c ("nvmem: Add apple-spmi-nvmem driver") Signed-off-by: Aelin Reidel Reported-by: Clayton Craft Tested-by: Clayton Craft Reviewed-by: Sven Peter Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223404.629248-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/nvmem/apple-spmi-nvmem.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/apple-spmi-nvmem.c b/drivers/nvmem/apple-spmi-nvmem.c index 88614005d5ce..7acb0c07d6ab 100644 --- a/drivers/nvmem/apple-spmi-nvmem.c +++ b/drivers/nvmem/apple-spmi-nvmem.c @@ -18,6 +18,22 @@ static const struct regmap_config apple_spmi_regmap_config = { .max_register = 0xffff, }; +static int apple_spmi_nvmem_read(void *priv, unsigned int offset, void *val, + size_t bytes) +{ + struct regmap *map = priv; + + return regmap_bulk_read(map, offset, val, bytes); +} + +static int apple_spmi_nvmem_write(void *priv, unsigned int offset, void *val, + size_t bytes) +{ + struct regmap *map = priv; + + return regmap_bulk_write(map, offset, val, bytes); +} + static int apple_spmi_nvmem_probe(struct spmi_device *sdev) { struct regmap *regmap; @@ -28,8 +44,8 @@ static int apple_spmi_nvmem_probe(struct spmi_device *sdev) .word_size = 1, .stride = 1, .size = 0xffff, - .reg_read = (void *)regmap_bulk_read, - .reg_write = (void *)regmap_bulk_write, + .reg_read = apple_spmi_nvmem_read, + .reg_write = apple_spmi_nvmem_write, }; regmap = devm_regmap_init_spmi_ext(sdev, &apple_spmi_regmap_config); From b5be879519291f139fa7b365fd0dbc84710e4919 Mon Sep 17 00:00:00 2001 From: Mathieu Dubois-Briand Date: Fri, 24 Jul 2026 23:34:04 +0100 Subject: [PATCH 07/15] nvmem: layouts: Add fixed-layout driver Current implementation isn't working well when device tree nodes have a phandle on a fixed-layout nvmem node. As the fixed layout is handled in nvmem core, no driver is ever associated with the layout, and the device consumer driver probe is deferred indefinitely. Remove the specific handling of fixed-layout and add a layout driver. This makes the fixed-layout similar to all other layouts, fixing the whole issue. Fixes: fc29fd821d9a ("nvmem: core: Rework layouts to become regular devices") Cc: stable@vger.kernel.org Reviewed-by: Miquel Raynal Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260724223404.629248-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman --- MAINTAINERS | 5 +++ drivers/nvmem/core.c | 24 +----------- drivers/nvmem/internals.h | 2 + drivers/nvmem/layouts.c | 11 ------ drivers/nvmem/layouts/Makefile | 1 + drivers/nvmem/layouts/fixed-layout.c | 58 ++++++++++++++++++++++++++++ include/linux/nvmem-provider.h | 6 +++ 7 files changed, 74 insertions(+), 33 deletions(-) create mode 100644 drivers/nvmem/layouts/fixed-layout.c diff --git a/MAINTAINERS b/MAINTAINERS index 716acfc3d7c1..1b044ddc68f9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10134,6 +10134,11 @@ F: drivers/base/firmware_loader/ F: rust/kernel/firmware.rs F: include/linux/firmware.h +FIXED-LAYOUT NVMEM LAYOUT DRIVER +M: Mathieu Dubois-Briand +S: Maintained +F: drivers/nvmem/layouts/fixed-layout.c + FLEXTIMER FTM-QUADDEC DRIVER M: Patrick Havelange L: linux-iio@vger.kernel.org diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index e871181751f3..2f971b059704 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -786,7 +786,7 @@ static int nvmem_validate_keepouts(struct nvmem_device *nvmem) return 0; } -static int nvmem_add_cells_from_dt(struct nvmem_device *nvmem, struct device_node *np) +int nvmem_add_cells_from_dt(struct nvmem_device *nvmem, struct device_node *np) { struct device *dev = &nvmem->dev; const __be32 *addr; @@ -834,29 +834,13 @@ static int nvmem_add_cells_from_dt(struct nvmem_device *nvmem, struct device_nod return 0; } +EXPORT_SYMBOL_GPL(nvmem_add_cells_from_dt); static int nvmem_add_cells_from_legacy_of(struct nvmem_device *nvmem) { return nvmem_add_cells_from_dt(nvmem, nvmem->dev.of_node); } -static int nvmem_add_cells_from_fixed_layout(struct nvmem_device *nvmem) -{ - struct device_node *layout_np; - int err = 0; - - layout_np = of_nvmem_layout_get_container(nvmem); - if (!layout_np) - return 0; - - if (of_device_is_compatible(layout_np, "fixed-layout")) - err = nvmem_add_cells_from_dt(nvmem, layout_np); - - of_node_put(layout_np); - - return err; -} - int nvmem_layout_register(struct nvmem_layout *layout) { int ret; @@ -1005,10 +989,6 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config) goto err_remove_cells; } - rval = nvmem_add_cells_from_fixed_layout(nvmem); - if (rval) - goto err_remove_cells; - dev_dbg(&nvmem->dev, "Registering nvmem device %s\n", config->name); rval = device_add(&nvmem->dev); diff --git a/drivers/nvmem/internals.h b/drivers/nvmem/internals.h index 18fed57270e5..f6d452b6a28f 100644 --- a/drivers/nvmem/internals.h +++ b/drivers/nvmem/internals.h @@ -35,6 +35,8 @@ struct nvmem_device { bool sysfs_cells_populated; }; +int nvmem_add_cells_from_dt(struct nvmem_device *nvmem, struct device_node *np); + #if IS_ENABLED(CONFIG_OF) int nvmem_layout_bus_register(void); void nvmem_layout_bus_unregister(void); diff --git a/drivers/nvmem/layouts.c b/drivers/nvmem/layouts.c index b90584e1b99e..07a34be9669c 100644 --- a/drivers/nvmem/layouts.c +++ b/drivers/nvmem/layouts.c @@ -125,11 +125,6 @@ static int nvmem_layout_create_device(struct nvmem_device *nvmem, return 0; } -static const struct of_device_id of_nvmem_layout_skip_table[] = { - { .compatible = "fixed-layout", }, - {} -}; - static int nvmem_layout_bus_populate(struct nvmem_device *nvmem, struct device_node *layout_dn) { @@ -142,12 +137,6 @@ static int nvmem_layout_bus_populate(struct nvmem_device *nvmem, return 0; } - /* Fixed layouts are parsed manually somewhere else for now */ - if (of_match_node(of_nvmem_layout_skip_table, layout_dn)) { - pr_debug("%s() - skipping %pOF node\n", __func__, layout_dn); - return 0; - } - if (of_node_check_flag(layout_dn, OF_POPULATED_BUS)) { pr_debug("%s() - skipping %pOF, already populated\n", __func__, layout_dn); diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile index 4940c9db0665..dd6c6c70b1a9 100644 --- a/drivers/nvmem/layouts/Makefile +++ b/drivers/nvmem/layouts/Makefile @@ -3,6 +3,7 @@ # Makefile for nvmem layouts. # +obj-$(CONFIG_NVMEM_LAYOUTS) += fixed-layout.o obj-$(CONFIG_NVMEM_LAYOUT_SL28_VPD) += sl28vpd.o obj-$(CONFIG_NVMEM_LAYOUT_ONIE_TLV) += onie-tlv.o obj-$(CONFIG_NVMEM_LAYOUT_U_BOOT_ENV) += u-boot-env.o diff --git a/drivers/nvmem/layouts/fixed-layout.c b/drivers/nvmem/layouts/fixed-layout.c new file mode 100644 index 000000000000..635d448b3dd2 --- /dev/null +++ b/drivers/nvmem/layouts/fixed-layout.c @@ -0,0 +1,58 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright 2026 Bootlin + * + * Authors: Mathieu Dubois-Briand + */ + +#include +#include + +#include "../internals.h" + +static int fixed_layout_add_cells(struct nvmem_layout *layout) +{ + struct device_node *np; + int ret; + + np = of_nvmem_layout_get_container(layout->nvmem); + if (!np) + return -ENOENT; + + ret = nvmem_add_cells_from_dt(layout->nvmem, np); + of_node_put(np); + + return ret; +} + +static int fixed_layout_probe(struct nvmem_layout *layout) +{ + layout->add_cells = fixed_layout_add_cells; + + return nvmem_layout_register(layout); +} + +static void fixed_layout_remove(struct nvmem_layout *layout) +{ + nvmem_layout_unregister(layout); +} + +static const struct of_device_id fixed_layout_of_match_table[] = { + { .compatible = "fixed-layout", }, + {}, +}; + +static struct nvmem_layout_driver fixed_layout_layout = { + .driver = { + .name = "fixed-layout", + .of_match_table = fixed_layout_of_match_table, + }, + .probe = fixed_layout_probe, + .remove = fixed_layout_remove, +}; +module_nvmem_layout_driver(fixed_layout_layout); + +MODULE_AUTHOR("Mathieu Dubois-Briand"); +MODULE_LICENSE("GPL"); +MODULE_DEVICE_TABLE(of, fixed_layout_of_match_table); +MODULE_DESCRIPTION("NVMEM fixed-layout driver"); diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h index f3b13da78aac..6063fe5b7784 100644 --- a/include/linux/nvmem-provider.h +++ b/include/linux/nvmem-provider.h @@ -214,6 +214,12 @@ static inline int nvmem_layout_register(struct nvmem_layout *layout) static inline void nvmem_layout_unregister(struct nvmem_layout *layout) {} +static inline int nvmem_add_cells_from_dt(struct nvmem_device *nvmem, + struct device_node *np) +{ + return -EOPNOTSUPP; +} + #endif /* CONFIG_NVMEM */ #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF) From dd7aea9ee2091cfae3a5e376af87aa106d7735cd Mon Sep 17 00:00:00 2001 From: Alice Ryhl Date: Mon, 27 Jul 2026 12:28:59 +0000 Subject: [PATCH 08/15] rust_binder: do not query current thread for all ioctls The get_current_thread() method is currently called for every ioctl to ensure that a Thread struct exists for the thread calling into the driver. However, not all ioctls require a Thread object, so this means we are unnecessarily creating these objects in cases where we don't need to. If said thread does not invoke BINDER_THREAD_EXIT on exit, Binder's Thread struct stays around until the fd is closed. For long-lived processes the Thread object is effectively leaked. Furthermore, when the BINDER_GET_NODE_DEBUG_INFO ioctl is invoked by libmemunreachable to ensure that objects reachable only through the Binder driver are not considered leaked, this is done from a fork of the process owning the fd, which means that it fails the group_leader check inside get_current_thread(). This results in EINVAL errors for this ioctl, causing libmemunreachable to report a false positive memory leak. Thus, do not invoke get_current_thread() for ioctls that do not require it. Signed-off-by: Alice Ryhl Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260727-binder-cur-thread-v1-1-8edf2b64e235@google.com Signed-off-by: Greg Kroah-Hartman --- drivers/android/binder/process.rs | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/android/binder/process.rs b/drivers/android/binder/process.rs index cdd1a9079726..5b8f73ec1931 100644 --- a/drivers/android/binder/process.rs +++ b/drivers/android/binder/process.rs @@ -1586,6 +1586,10 @@ fn ioctl_write_only( cmd: u32, reader: &mut UserSliceReader, ) -> Result { + if cmd == uapi::BINDER_FREEZE { + return ioctl_freeze(reader); + } + let thread = this.get_current_thread()?; match cmd { uapi::BINDER_SET_MAX_THREADS => this.set_max_threads(reader.read()?), @@ -1597,7 +1601,6 @@ fn ioctl_write_only( uapi::BINDER_ENABLE_ONEWAY_SPAM_DETECTION => { this.set_oneway_spam_detection_enabled(reader.read()?) } - uapi::BINDER_FREEZE => ioctl_freeze(reader)?, _ => return Err(EINVAL), } Ok(()) @@ -1612,15 +1615,16 @@ fn ioctl_write_read( cmd: u32, data: UserSlice, ) -> Result { - let thread = this.get_current_thread()?; let blocking = (file.flags() & file::flags::O_NONBLOCK) == 0; match cmd { - uapi::BINDER_WRITE_READ => thread.write_read(data, blocking)?, + uapi::BINDER_WRITE_READ => this.get_current_thread()?.write_read(data, blocking)?, uapi::BINDER_GET_NODE_DEBUG_INFO => this.get_node_debug_info(data)?, uapi::BINDER_GET_NODE_INFO_FOR_REF => this.get_node_info_from_ref(data)?, uapi::BINDER_VERSION => this.version(data)?, uapi::BINDER_GET_FROZEN_INFO => get_frozen_status(data)?, - uapi::BINDER_GET_EXTENDED_ERROR => thread.get_extended_error(data)?, + uapi::BINDER_GET_EXTENDED_ERROR => { + this.get_current_thread()?.get_extended_error(data)? + } _ => return Err(EINVAL), } Ok(()) From b0495bb58af06a7de4628c72d500e3d5e180d808 Mon Sep 17 00:00:00 2001 From: Alexander Usyskin Date: Sun, 19 Jul 2026 12:57:55 +0300 Subject: [PATCH 09/15] mei: pull kvfree out of spinlock The read buffer allocation was changed from kmalloc() to kvmalloc(). This buffer is part of mei_cl_cb structure that can be queued in rd_complete queue protected by spinlock. Releasing the structure leads to errors like below when freeing buffer that allocated non-contiguous: BUG: sleeping function called from invalid context at mm/vmalloc.c:3448 Separate mei_cl_cb structure dequeue and release to perform only dequeue under spinlock and push release out of spinlock. Cc: stable Fixes: 4adf613e01bf ("mei: use kvmalloc for read buffer") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16359 Reviewed-by: Menachem Adin Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260719-kvfree_out_of_spinlock-v1-1-e07d6333bea7@intel.com Signed-off-by: Greg Kroah-Hartman --- drivers/misc/mei/client.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c index 643b0039cc72..26d2b2742d50 100644 --- a/drivers/misc/mei/client.c +++ b/drivers/misc/mei/client.c @@ -425,18 +425,24 @@ static void mei_io_tx_list_free_cl(struct list_head *head, } /** - * mei_io_list_free_fp - free cb from a list that matches file pointer + * mei_io_rd_list_free_fp - free cb from a rd_completed list that matches file pointer * - * @head: io list + * @cl: host client * @fp: file pointer (matching cb file object), may be NULL */ -static void mei_io_list_free_fp(struct list_head *head, const struct file *fp) +static void mei_io_rd_list_free_fp(struct mei_cl *cl, const struct file *fp) { struct mei_cl_cb *cb, *next; + LIST_HEAD(cmpl_list); - list_for_each_entry_safe(cb, next, head, list) + spin_lock(&cl->rd_completed_lock); + list_for_each_entry_safe(cb, next, &cl->rd_completed, list) if (!fp || fp == cb->fp) - mei_io_cb_free(cb); + list_move(&cb->list, &cmpl_list); + spin_unlock(&cl->rd_completed_lock); + + list_for_each_entry_safe(cb, next, &cmpl_list, list) + mei_io_cb_free(cb); } /** @@ -565,9 +571,7 @@ int mei_cl_flush_queues(struct mei_cl *cl, const struct file *fp) mei_io_list_flush_cl(&cl->dev->ctrl_rd_list, cl); mei_cl_free_pending(cl); } - spin_lock(&cl->rd_completed_lock); - mei_io_list_free_fp(&cl->rd_completed, fp); - spin_unlock(&cl->rd_completed_lock); + mei_io_rd_list_free_fp(cl, fp); return 0; } @@ -1401,7 +1405,7 @@ void mei_cl_add_rd_completed(struct mei_cl *cl, struct mei_cl_cb *cb) } /** - * mei_cl_del_rd_completed - free read completed callback with lock + * mei_cl_del_rd_completed - unlink read completed callback with lock and free it * * @cl: host client * @cb: callback block @@ -1410,8 +1414,9 @@ void mei_cl_add_rd_completed(struct mei_cl *cl, struct mei_cl_cb *cb) void mei_cl_del_rd_completed(struct mei_cl *cl, struct mei_cl_cb *cb) { spin_lock(&cl->rd_completed_lock); - mei_io_cb_free(cb); + list_del_init(&cb->list); spin_unlock(&cl->rd_completed_lock); + mei_io_cb_free(cb); } /** From f1a3a9946aab611dd2200c01ff122f64b033dad2 Mon Sep 17 00:00:00 2001 From: Babanpreet Singh Date: Tue, 14 Jul 2026 04:29:10 +0000 Subject: [PATCH 10/15] counter: microchip-tcb-capture: Fix DT channel validation mchp_tc_probe() reads the devicetree "reg" cell - a u32, per the API contract of of_property_read_u32_index() - into a signed int, so the bounds check "channel > 2" fails to reject cell values at or above 0x80000000: reinterpreted as a negative int, they compare below 2 and pass validation. A malformed devicetree can therefore drive a negative channel into the ATMEL_TC_REG() offset arithmetic, making the driver access syscon regmap offsets outside the TC block's register window, and into the "t%d_clk" clock-name formatting, where it truncates clk_name (sized for "t0_clk".."t2_clk"). Declare channel as u32, matching the API contract; the unsigned comparison then rejects everything except channels 0..2. Adjust the format specifier to %u accordingly, which also resolves the W=1 warning that exposed the gap: microchip-tcb-capture.c:520:56: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Wformat-truncation=] note: directive argument in the range [-2147483648, 2] No behavior change for well-formed devicetrees: channels 0..2 take identical paths before and after. Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Assisted-by: Claude:claude-fable-5 [gcc W=1] Signed-off-by: Babanpreet Singh Reviewed-by: Joshua Crofts Link: https://lore.kernel.org/r/20260714042910.7-1-bbnpreetsingh@gmail.com Signed-off-by: William Breathitt Gray --- drivers/counter/microchip-tcb-capture.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c index 19d457ae4c3b..e53a8390756b 100644 --- a/drivers/counter/microchip-tcb-capture.c +++ b/drivers/counter/microchip-tcb-capture.c @@ -483,7 +483,7 @@ static int mchp_tc_probe(struct platform_device *pdev) char clk_name[7]; struct regmap *regmap; struct clk *clk[3]; - int channel; + u32 channel; int ret, i; counter = devm_counter_alloc(&pdev->dev, sizeof(*priv)); @@ -517,7 +517,7 @@ static int mchp_tc_probe(struct platform_device *pdev) priv->channel[i] = channel; - snprintf(clk_name, sizeof(clk_name), "t%d_clk", channel); + snprintf(clk_name, sizeof(clk_name), "t%u_clk", channel); clk[i] = of_clk_get_by_name(np->parent, clk_name); if (IS_ERR(clk[i])) { From bea79063a35121e49a86801671cca56fc4d83f7d Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Sun, 2 Aug 2026 22:35:36 +0200 Subject: [PATCH 11/15] docs: threat-model: clarify "security bug" vs "vulnerability" Throwing an LLM (Opus 5) at a file looking for random bugs after having read the threat model made it ignore certain bugs it found because "the threat model said they must be ignored". When asked why, the LLM rightfully reported the ambiguous wording used at a few places: "is not a security bug", which can also be read as "is not a bug", despite the rest of the document. That is particularly true when the LLM decides to look for info using grep. This change replaces "security bug" with "vulnerability" at a few places in order to remove this identified ambiguity, and uses "bugs" instead of issues in two such sentences to insist that what is described remains a bug. Cc: Greg KH Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260802203540.3453-2-w@1wt.eu Signed-off-by: Greg Kroah-Hartman --- Documentation/process/threat-model.rst | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst index 9dd8011dde82..7990673072c4 100644 --- a/Documentation/process/threat-model.rst +++ b/Documentation/process/threat-model.rst @@ -98,11 +98,11 @@ measures whose purpose is to avoid crossing a security boundary when certain classes of bugs are found, but a failure of these extra protections do not constitute a vulnerability alone. -What does not constitute a security bug ---------------------------------------- +What classes of problems are not considered vulnerabilities +----------------------------------------------------------- In the Linux kernel's threat model, the following classes of problems are -**NOT** considered as Linux Kernel security bugs. However, when it is believed +**NOT** considered Linux Kernel vulnerabilities. However, when it is believed that the kernel could do better, they should be reported, so that they can be reviewed and fixed where reasonably possible, but they will be handled as any regular bug: @@ -111,8 +111,8 @@ regular bug: * outdated kernels and particularly end-of-life branches are out of the scope of the kernel's threat model: administrators are responsible for keeping - their system up to date. For a bug to qualify as a security bug, it must be - demonstrated that it affects actively maintained versions. + their system up to date. For a bug to qualify as a vulnerability, it must + be demonstrated that it affects actively maintained versions. * build-level: changes to the kernel configuration that are explicitly documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or @@ -178,7 +178,7 @@ regular bug: involving tens of millions of threads, tens of thousands of CPUs, unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds). - * issues whose reproduction requires hardware modification or emulation, + * bugs whose reproduction requires hardware modification or emulation, including fake USB devices that pretend to be another one. * as well as issues that can be triggered at a cost that is orders of @@ -208,17 +208,17 @@ regular bug: messages. * Leaks of kernel memory addresses/pointers do not constitute an immediately - exploitable vector and are not security bugs, though they must be reported - and fixed. + exploitable vector and are not vulnerabilities, though they must be + reported and fixed. * **Crafted file system images**: * bugs triggered by mounting a corrupted or maliciously crafted file system - image are generally not security bugs, as the kernel assumes the underlying + image are generally not vulnerabilities, as the kernel assumes the underlying storage media is under the administrator's control, unless the filesystem driver is specifically documented as being hardened against untrusted media. - * issues that are resolved, mitigated, or detected by running a filesystem + * bugs that are resolved, mitigated, or detected by running a filesystem consistency check (fsck) on the image prior to mounting. * **Physical access**: @@ -232,4 +232,4 @@ regular bug: * **Functional and performance regressions**: Any issue that can be mitigated by setting proper permissions and limits - doesn't qualify as a security bug. + doesn't qualify as a vulnerability. From 11f46e30e6885734be609e337e65a4784bdd282d Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Sun, 2 Aug 2026 22:35:37 +0200 Subject: [PATCH 12/15] docs: threat-model: move fake devices out of "non production use" When originally writing the "fake USB device" entry, it was difficult to find a suitable section for it and it ended up in "non production use" but that doesn't fit particularly well. Actually it's very similar to crafted filesystems, it's a matter of spec violation. Both drivers and FS are written against a spec, and what the threat model doesn't cover is out-of-spec use. So let's move the entry there and rename the crafted FS entry to "Non-conforming devices and media" instead. Overall it looks more consistent. The spec was tested agains Qwen3.6-27B-Architect-Polaris2-Fable-B-F451, Opus-5 and Gemini by reading the threat-model file, then reading a tens of FS and driver fixes, and they were now all properly classified as regular bugs, except two that Gemini and Opus rightfully classified as vulns (Qwen didn't spot the security potential but that's out of our scope). Cc: Greg KH Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260802203540.3453-3-w@1wt.eu Signed-off-by: Greg Kroah-Hartman --- Documentation/process/threat-model.rst | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst index 7990673072c4..a68be888ce8e 100644 --- a/Documentation/process/threat-model.rst +++ b/Documentation/process/threat-model.rst @@ -178,9 +178,6 @@ regular bug: involving tens of millions of threads, tens of thousands of CPUs, unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds). - * bugs whose reproduction requires hardware modification or emulation, - including fake USB devices that pretend to be another one. - * as well as issues that can be triggered at a cost that is orders of magnitude higher than the expected benefits (e.g. fully functional keyboard emulator only to retrieve 7 uninitialized bytes in a structure, or @@ -211,16 +208,24 @@ regular bug: exploitable vector and are not vulnerabilities, though they must be reported and fixed. -* **Crafted file system images**: +* **Non-conforming devices and media**: + + Drivers are implemented against a specification. When a device or a storage + medium violates the specification its driver was written against, the + resulting misbehaviour is a regular bug to be fixed, not a vulnerability, + unless the driver is specifically documented as being hardened against + hostile inputs. The following are therefore not considered vulnerabilities: * bugs triggered by mounting a corrupted or maliciously crafted file system - image are generally not vulnerabilities, as the kernel assumes the underlying - storage media is under the administrator's control, unless the filesystem - driver is specifically documented as being hardened against untrusted media. - - * bugs that are resolved, mitigated, or detected by running a filesystem + image: mounting a block device is a privileged operation (see above), and + the administrator is responsible for the media they mount. This includes + issues that are resolved, mitigated, or detected by running a filesystem consistency check (fsck) on the image prior to mounting. + * bugs whose reproduction requires hardware modification or emulation, + including fake USB devices that pretend to be another one, or devices + reporting values outside their documented ranges. + * **Physical access**: Issues that require physical access to the machine, hardware modification, or From e447f7f33fa0a50d42d0539c161a662e67bd1a2c Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Sun, 2 Aug 2026 22:35:38 +0200 Subject: [PATCH 13/15] docs: security-bugs: clarify what counts as a valid version Too often we're getting reports saying "still valid in latest mainline" with no indication of when this was verified, making this indication pointless. Let's clarify it and insist on having a version or commit ID, and that the version must necessarily be for a kernel.org kernel and not a distro one. Cc: Greg KH Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260802203540.3453-4-w@1wt.eu Signed-off-by: Greg Kroah-Hartman --- Documentation/process/security-bugs.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index 3c51ddde31dd..6f7c21515e9e 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -18,6 +18,10 @@ information is helpful. The following information are absolutely necessary in **any** security bug report: * **affected kernel version range**: with no version indication, your report + will not be processed. Note that a time-dependent version such as "latest + mainline" is not acceptable. A stable identifier such as a commit ID or an + exact version is required. Versions designating kernels not coming from + kernel.org (such as distro kernels) are meaningless to maintainers and will not be processed. A significant part of reports are for bugs that have already been fixed, so it is extremely important that vulnerabilities are verified on recent versions (development tree or latest stable From 3d7c44f73765d98665fb97a4fb89c002c88ba1b9 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Sun, 2 Aug 2026 22:35:39 +0200 Subject: [PATCH 14/15] docs: coding-assistant: explain important steps when looking for bugs Due to the increasing capabilities of available AI models, it's becoming common to see them used to find bugs anywhere. Unfortunately the quality of reports (especially when they're believed to be security relevant) is still lacking a lot. Let's add a section dedicated to bug finding, explaining the few mandatory steps (noting commit ID, writing the fix from the session that found the bug, building and testing, etc). This was tested both against Qwen3.6-27B-Architect-Polaris2-Fable-B-F451 running under Hermes, and Opus-5, and both followed the instructions to the letter, verifying their results and checking threat-model.rst to decline the vulnerability aspect. At least in the current form it's expected to improve the situation a little bit. Cc: Greg KH Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260802203540.3453-5-w@1wt.eu Signed-off-by: Greg Kroah-Hartman --- Documentation/process/coding-assistants.rst | 37 +++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst index 899f4459c52d..e71df7d28467 100644 --- a/Documentation/process/coding-assistants.rst +++ b/Documentation/process/coding-assistants.rst @@ -57,3 +57,40 @@ Basic development tools (git, gcc, make, editors) should not be listed. Example:: Assisted-by: Claude:claude-3-opus coccinelle sparse + +Procedure for finding and fixing bugs +===================================== + +When an AI assistant is used to find and fix bugs, it **MUST** follow at least +these steps: + +1. Before starting, read the whole process documentation listed above, as well + as any other document mentioned in the request. Do not rely on isolated + parts found by keyword search. +2. Note the commit ID and Locate a bug as instructed. +3. For any bug found that is not trivial, verify that it looks real by + attempting to create a reproducer to demonstrate it. Lacking it may cause + the report to be ignored, as many unverified bug reports sent to maintainers + happen to be invalid. Stop here if it finally looks wrong. +4. Write a fix for the bug. This part is not optional: except in a few very + rare cases, an AI assistant able to find a bug is able to fix it. Note that + fixes written in the same session as used to find the bug will generally + lead to better and more accurate fixes as the LLM's reasoning context + remains present. +5. Build and verify that the fix works either using the reproducer or by + re-running a complete analysis; drop any fix that doesn't work and try + another one. The fix must not add build warnings and must pass the + checkpatch.pl checks (see submitting-patches.rst). +6. Commit the working fix with a detailed message describing the problem, the + solution and a Fixes tag. Do not add a Signed-off-by tag, and add an + Assisted-by tag, as described above. +7. Identify the maintainers and lists using scripts/get_maintainer.pl. + Documentation/process/security-bugs.rst shows how to do that. +8. Indicate what could not be done. If the fix could not be built or tested, or + if no reproducer could be produced, say so explicitly: maintainers currently + waste too much time analyzing unverified reports and untested fixes. +9. Read Documentation/process/threat-model.rst to determine whether the bug is + a vulnerability or a regular bug, and leave the result to the reporter for + review (the assistant must never send anything itself). Regular bugs are + submitted as described in Documentation/process/submitting-patches.rst, + vulnerabilities as described in Documentation/process/security-bugs.rst. From 6ffecfe0805e8811e7637e8f381b6740a3e9767b Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Sun, 2 Aug 2026 22:35:40 +0200 Subject: [PATCH 15/15] docs: security-bugs: clarify some mandatory steps for AI reports The security team is still seeing a lot of reports lacking a full patch and showing missing contents and formatting issues. Since AI assistants tend to be better than humans at following instructions, let's defer to coding-assistants.rst to follow mandatory steps, and insist on the plain text format, as well as asking for recipient addresses and an e-mail client setup hint to be mentioned early in the report for the reporter. Also add a link to https://github.com/masoncl/kres.git which contains way more advanced and detailed steps for those willing to go further. Tested with Opus-5 and Qwen3.6-27B-Architect-Polaris2-Fable-B-F451, both of which proceeded according to instructions. Cc: Greg KH Cc: Chris Mason Signed-off-by: Willy Tarreau Link: https://patch.msgid.link/20260802203540.3453-6-w@1wt.eu Signed-off-by: Greg Kroah-Hartman --- Documentation/process/security-bugs.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index 6f7c21515e9e..c7dfecc87764 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -229,6 +229,28 @@ there is no need to consume a maintainer's time with an unimportant report. If the issue is clearly trivial and publicly discoverable, you should report it directly to the public mailing lists. +At the very least, when using an AI assistant to find and report bugs, make the +assistant read this file and threat-model.rst before proceeding, and have it +follow the procedure described in coding-assistants.rst: work on an up-to-date +mainline tree and note the commit ID, verify the bug is real, write a fix, +build it warning-free and checkpatch-clean, commit it with a Fixes tag, and +identify the maintainers with get_maintainer.pl. + +On top of that procedure, the AI assistant **MUST**: + +1. Prepare a plain-text report explaining the problem. It must contain the + four items listed at the top of this file as absolutely necessary: the + affected version or commit ID noted while following the procedure above, + the description of the problem, the reproducer or its status, and the + triggering conditions. +2. Start the report with a temporary section listing the recipients' addresses + (maintainers+list for the patch, maintainers only for the report and + reproducer), and with instructions reminding the reporter to check that + their email client is properly setup (see email-clients.rst), and leave it + to the reporter to remove that temporary section. + +A more detailed process is covered at https://github.com/masoncl/kres.git. + Sending the report ------------------