Hi Srini, These are not fixes from a FastRPC use case I am running, and I do not have FastRPC hardware for runtime testing. They came from static code review. I used an AI coding assistant during discovery and drafting, then reviewed the changes and ran strict checkpatch and focused compile checks before sending them.
I had not completed a proper reconciliation against the current mailing-list work before sending the patches independently. That, and sending so many related changes as separate threads, was a process mistake. I am pausing this set. I will first compare every item with the existing list series, drop duplicates and weak findings, and re-audit the lifetime changes in light of the reported concurrency concerns. I will only return with a small ordered series if anything remains defensible, with the testing limits stated explicitly. Thanks, Yousef On Wed, 1 Jul 2026 21:05:37 +0100, Srinivas Kandagatla <[email protected]> wrote: > On 6/24/26 6:44 PM, Yousef Alhouseen wrote: > > fastrpc_get_buff_overlaps() builds end addresses from user ranges. > > > > A wrapped end can understate the payload size. > > > > It can also feed bad ranges into the invoke metadata. > > > > Reject invoke buffers whose pointer plus length overflows. > > > > Signed-off-by: Yousef Alhouseen <[email protected]> > You have sent 11 patches independently, I would prefer it to be sent as > single series. > > Are these patches fixing anything that your usecases are hitting? > > Have you looked at the patches in the mailing list which fixes some of > these issues? > > Or > > Is AI generating these patches ? > > --srini > > > --- > > drivers/misc/fastrpc.c | 18 +++++++++++++++--- > > 1 file changed, 15 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > > index f3a493845..ba4ade874 100644 > > --- a/drivers/misc/fastrpc.c > > +++ b/drivers/misc/fastrpc.c > > @@ -13,6 +13,7 @@ > > #include <linux/module.h> > > #include <linux/of_address.h> > > #include <linux/of.h> > > +#include <linux/overflow.h> > > #include <linux/platform_device.h> > > #include <linux/sort.h> > > #include <linux/of_platform.h> > > @@ -607,14 +608,17 @@ static int olaps_cmp(const void *a, const void *b) > > return st == 0 ? ed : st; > > } > > > > -static void fastrpc_get_buff_overlaps(struct fastrpc_invoke_ctx *ctx) > > +static int fastrpc_get_buff_overlaps(struct fastrpc_invoke_ctx *ctx) > > { > > u64 max_end = 0; > > int i; > > > > for (i = 0; i < ctx->nbufs; ++i) { > > ctx->olaps[i].start = ctx->args[i].ptr; > > - ctx->olaps[i].end = ctx->olaps[i].start + ctx->args[i].length; > > + if (check_add_overflow(ctx->olaps[i].start, > > + ctx->args[i].length, > > + &ctx->olaps[i].end)) > > + return -EOVERFLOW; > > ctx->olaps[i].raix = i; > > } > > > > @@ -641,6 +645,8 @@ static void fastrpc_get_buff_overlaps(struct > > fastrpc_invoke_ctx *ctx) > > max_end = ctx->olaps[i].end; > > } > > } > > + > > + return 0; > > } > > > > static struct fastrpc_invoke_ctx *fastrpc_context_alloc( > > @@ -675,7 +681,13 @@ static struct fastrpc_invoke_ctx > > *fastrpc_context_alloc( > > return ERR_PTR(-ENOMEM); > > } > > ctx->args = args; > > - fastrpc_get_buff_overlaps(ctx); > > + ret = fastrpc_get_buff_overlaps(ctx); > > + if (ret) { > > + kfree(ctx->olaps); > > + kfree(ctx->maps); > > + kfree(ctx); > > + return ERR_PTR(ret); > > + } > > } > > > > /* Released in fastrpc_context_put() */
