1. Patchew
  2. linux
  3. [PATCH v2 0/4] Add missing bug fixes
  4. View patch

[PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash

Jianping Li posted 4 patches 3 weeks, 4 days ago
[PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Jianping Li 3 weeks, 4 days ago 
From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

The fastrpc_buf_free function currently does not handle the case where
the input buffer pointer (buf) is NULL. This can lead to a null pointer
dereference, causing a crash or undefined behavior when the function
attempts to access members of the buf structure. Add a NULL check to
ensure safe handling of NULL pointers and prevent potential crashes.

Fixes: c68cfb718c8f9 ("misc: fastrpc: Add support for context Invoke method")
Cc: stable@kernel.org
Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 4f5a79c50f58..515a43c9d95d 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -414,6 +414,9 @@ static int fastrpc_map_lookup(struct fastrpc_user *fl, int fd,
 
 static void fastrpc_buf_free(struct fastrpc_buf *buf)
 {
+	if (!buf)
+		return;
+
 	dma_free_coherent(buf->dev, buf->size, buf->virt,
 			  fastrpc_ipa_to_dma_addr(buf->fl->cctx, buf->dma_addr));
 	kfree(buf);
@@ -510,8 +513,7 @@ static void fastrpc_context_free(struct kref *ref)
 	for (i = 0; i < ctx->nbufs; i++)
 		fastrpc_map_put(ctx->maps[i]);
 
-	if (ctx->buf)
-		fastrpc_buf_free(ctx->buf);
+	fastrpc_buf_free(ctx->buf);
 
 	spin_lock_irqsave(&cctx->lock, flags);
 	idr_remove(&cctx->ctx_idr, ctx->ctxid >> 4);
@@ -1591,8 +1593,7 @@ static int fastrpc_device_release(struct inode *inode, struct file *file)
 	list_del(&fl->user);
 	spin_unlock_irqrestore(&cctx->lock, flags);
 
-	if (fl->init_mem)
-		fastrpc_buf_free(fl->init_mem);
+	fastrpc_buf_free(fl->init_mem);
 
 	list_for_each_entry_safe(ctx, n, &fl->pending, node) {
 		list_del(&ctx->node);
@@ -2492,8 +2493,7 @@ static void fastrpc_rpmsg_remove(struct rpmsg_device *rpdev)
 	list_for_each_entry_safe(buf, b, &cctx->invoke_interrupted_mmaps, node)
 		list_del(&buf->node);
 
-	if (cctx->remote_heap)
-		fastrpc_buf_free(cctx->remote_heap);
+	fastrpc_buf_free(cctx->remote_heap);
 
 	of_platform_depopulate(&rpdev->dev);
 
-- 
2.43.0
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Greg KH 3 weeks, 3 days ago 
On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> 
> The fastrpc_buf_free function currently does not handle the case where
> the input buffer pointer (buf) is NULL. This can lead to a null pointer
> dereference, causing a crash or undefined behavior when the function
> attempts to access members of the buf structure. Add a NULL check to
> ensure safe handling of NULL pointers and prevent potential crashes.

What caller passes in NULL here?  I did a quick look, and see where the
callers check this properly if it could be NULL, otherwise it all looks
sane to me.  What in-kernel user is causing a crash here?  Why not fix
the caller up instead?

thanks,

greg k-h
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Jianping 1 week ago 

On 1/16/2026 10:49 PM, Greg KH wrote:
> On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>
>> The fastrpc_buf_free function currently does not handle the case where
>> the input buffer pointer (buf) is NULL. This can lead to a null pointer
>> dereference, causing a crash or undefined behavior when the function
>> attempts to access members of the buf structure. Add a NULL check to
>> ensure safe handling of NULL pointers and prevent potential crashes.
> 
> What caller passes in NULL here?  I did a quick look, and see where the
> callers check this properly if it could be NULL, otherwise it all looks
> sane to me.  What in-kernel user is causing a crash here?  Why not fix
> the caller up instead?
> 
> thanks,
> 
> greg k-h

It's a saftety coding: to eliminate NULL checks on the caller side, as 
we do in a lot of other kernel API.

And it was pointed out in the v1 patch discussion that this change was 
needed:
https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/

Thanks,
Jianping.
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Greg KH 1 week ago 
On Mon, Feb 02, 2026 at 03:13:10PM +0800, Jianping wrote:
> 
> 
> On 1/16/2026 10:49 PM, Greg KH wrote:
> > On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
> > > From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> > > 
> > > The fastrpc_buf_free function currently does not handle the case where
> > > the input buffer pointer (buf) is NULL. This can lead to a null pointer
> > > dereference, causing a crash or undefined behavior when the function
> > > attempts to access members of the buf structure. Add a NULL check to
> > > ensure safe handling of NULL pointers and prevent potential crashes.
> > 
> > What caller passes in NULL here?  I did a quick look, and see where the
> > callers check this properly if it could be NULL, otherwise it all looks
> > sane to me.  What in-kernel user is causing a crash here?  Why not fix
> > the caller up instead?
> > 
> > thanks,
> > 
> > greg k-h
> 
> It's a saftety coding: to eliminate NULL checks on the caller side, as we do
> in a lot of other kernel API.

But you do not do that for all functions in the kernel, otherwise the
kernel would be full of checks that are never hit at all.

> And it was pointed out in the v1 patch discussion that this change was
> needed:
> https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/

Were the checks removed from the caller side like was asked for?

Also, your changelog makes it sound like this is a real bugfix for
something, when it is not at all, which is what I object to the most.
Don't make scary changelogs for things that are not actually happening.

thanks,

greg k-h
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Jianping 6 days, 3 hours ago 

On 2/2/2026 4:41 PM, Greg KH wrote:
> On Mon, Feb 02, 2026 at 03:13:10PM +0800, Jianping wrote:
>>
>>
>> On 1/16/2026 10:49 PM, Greg KH wrote:
>>> On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
>>>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>>>
>>>> The fastrpc_buf_free function currently does not handle the case where
>>>> the input buffer pointer (buf) is NULL. This can lead to a null pointer
>>>> dereference, causing a crash or undefined behavior when the function
>>>> attempts to access members of the buf structure. Add a NULL check to
>>>> ensure safe handling of NULL pointers and prevent potential crashes.
>>>
>>> What caller passes in NULL here?  I did a quick look, and see where the
>>> callers check this properly if it could be NULL, otherwise it all looks
>>> sane to me.  What in-kernel user is causing a crash here?  Why not fix
>>> the caller up instead?
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> It's a saftety coding: to eliminate NULL checks on the caller side, as we do
>> in a lot of other kernel API.
> 
> But you do not do that for all functions in the kernel, otherwise the
> kernel would be full of checks that are never hit at all.
To clarify the intention: this change was not triggered by any real 
crash in current callers. The motivation came from the v1 review 
discussion [1], where it was suggested that a NULL check in 
fastrpc_buf_free() would allow simplifying some of the caller paths.

[1] 
https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
> 
>> And it was pointed out in the v1 patch discussion that this change was
>> needed:
>> https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
> 
> Were the checks removed from the caller side like was asked for?

Currently, I have placed the check inside the API and removed all the 
checks outside the API.

> 
> Also, your changelog makes it sound like this is a real bugfix for
> something, when it is not at all, which is what I object to the most.
> Don't make scary changelogs for things that are not actually happening.

You are correct. I will modify the commit text that caused the 
misunderstanding.

> 
> thanks,
> 
> greg k-h
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Bjorn Andersson 5 days, 17 hours ago 
On Tue, Feb 03, 2026 at 08:08:16PM +0800, Jianping wrote:
> 
> 
> On 2/2/2026 4:41 PM, Greg KH wrote:
> > On Mon, Feb 02, 2026 at 03:13:10PM +0800, Jianping wrote:
> > > 
> > > 
> > > On 1/16/2026 10:49 PM, Greg KH wrote:
> > > > On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
> > > > > From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> > > > > 
> > > > > The fastrpc_buf_free function currently does not handle the case where
> > > > > the input buffer pointer (buf) is NULL. This can lead to a null pointer
> > > > > dereference, causing a crash or undefined behavior when the function
> > > > > attempts to access members of the buf structure. Add a NULL check to
> > > > > ensure safe handling of NULL pointers and prevent potential crashes.
> > > > 
> > > > What caller passes in NULL here?  I did a quick look, and see where the
> > > > callers check this properly if it could be NULL, otherwise it all looks
> > > > sane to me.  What in-kernel user is causing a crash here?  Why not fix
> > > > the caller up instead?
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > It's a saftety coding: to eliminate NULL checks on the caller side, as we do
> > > in a lot of other kernel API.
> > 
> > But you do not do that for all functions in the kernel, otherwise the
> > kernel would be full of checks that are never hit at all.
> To clarify the intention: this change was not triggered by any real crash in
> current callers. The motivation came from the v1 review discussion [1],
> where it was suggested that a NULL check in fastrpc_buf_free() would allow
> simplifying some of the caller paths.
> 
> [1] https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
> > 
> > > And it was pointed out in the v1 patch discussion that this change was
> > > needed:
> > > https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
> > 
> > Were the checks removed from the caller side like was asked for?
> 
> Currently, I have placed the check inside the API and removed all the checks
> outside the API.
> 
> > 
> > Also, your changelog makes it sound like this is a real bugfix for
> > something, when it is not at all, which is what I object to the most.
> > Don't make scary changelogs for things that are not actually happening.
> 
> You are correct. I will modify the commit text that caused the
> misunderstanding.
> 

You should then also drop Cc: stable and Fixes:, as this is no longer a
bug fix. And make sure you don't put actual bug fixes after this one in
the series (i.e. it probably shouldn't be patch 1/4).

Regards,
Bjorn

> > 
> > thanks,
> > 
> > greg k-h
> 
>
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Jianping 4 days, 6 hours ago 

On 2/4/2026 5:32 AM, Bjorn Andersson wrote:
> On Tue, Feb 03, 2026 at 08:08:16PM +0800, Jianping wrote:
>>
>>
>> On 2/2/2026 4:41 PM, Greg KH wrote:
>>> On Mon, Feb 02, 2026 at 03:13:10PM +0800, Jianping wrote:
>>>>
>>>>
>>>> On 1/16/2026 10:49 PM, Greg KH wrote:
>>>>> On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
>>>>>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>>>>>
>>>>>> The fastrpc_buf_free function currently does not handle the case where
>>>>>> the input buffer pointer (buf) is NULL. This can lead to a null pointer
>>>>>> dereference, causing a crash or undefined behavior when the function
>>>>>> attempts to access members of the buf structure. Add a NULL check to
>>>>>> ensure safe handling of NULL pointers and prevent potential crashes.
>>>>>
>>>>> What caller passes in NULL here?  I did a quick look, and see where the
>>>>> callers check this properly if it could be NULL, otherwise it all looks
>>>>> sane to me.  What in-kernel user is causing a crash here?  Why not fix
>>>>> the caller up instead?
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>
>>>> It's a saftety coding: to eliminate NULL checks on the caller side, as we do
>>>> in a lot of other kernel API.
>>>
>>> But you do not do that for all functions in the kernel, otherwise the
>>> kernel would be full of checks that are never hit at all.
>> To clarify the intention: this change was not triggered by any real crash in
>> current callers. The motivation came from the v1 review discussion [1],
>> where it was suggested that a NULL check in fastrpc_buf_free() would allow
>> simplifying some of the caller paths.
>>
>> [1] https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
>>>
>>>> And it was pointed out in the v1 patch discussion that this change was
>>>> needed:
>>>> https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
>>>
>>> Were the checks removed from the caller side like was asked for?
>>
>> Currently, I have placed the check inside the API and removed all the checks
>> outside the API.
>>
>>>
>>> Also, your changelog makes it sound like this is a real bugfix for
>>> something, when it is not at all, which is what I object to the most.
>>> Don't make scary changelogs for things that are not actually happening.
>>
>> You are correct. I will modify the commit text that caused the
>> misunderstanding.
>>
> 
> You should then also drop Cc: stable and Fixes:, as this is no longer a
> bug fix. And make sure you don't put actual bug fixes after this one in
> the series (i.e. it probably shouldn't be patch 1/4).
> 
> Regards,
> Bjorn

Thank Bjorn for the reminder, I will adjust the order of my patch.

> 
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>>
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Jianping 6 days, 4 hours ago 

On 2/2/2026 4:41 PM, Greg KH wrote:
> On Mon, Feb 02, 2026 at 03:13:10PM +0800, Jianping wrote:
>>
>>
>> On 1/16/2026 10:49 PM, Greg KH wrote:
>>> On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
>>>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>>>
>>>> The fastrpc_buf_free function currently does not handle the case where
>>>> the input buffer pointer (buf) is NULL. This can lead to a null pointer
>>>> dereference, causing a crash or undefined behavior when the function
>>>> attempts to access members of the buf structure. Add a NULL check to
>>>> ensure safe handling of NULL pointers and prevent potential crashes.
>>>
>>> What caller passes in NULL here?  I did a quick look, and see where the
>>> callers check this properly if it could be NULL, otherwise it all looks
>>> sane to me.  What in-kernel user is causing a crash here?  Why not fix
>>> the caller up instead?
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> It's a saftety coding: to eliminate NULL checks on the caller side, as we do
>> in a lot of other kernel API.
> 
> But you do not do that for all functions in the kernel, otherwise the
> kernel would be full of checks that are never hit at all.
To clarify the intention: this change was not triggered by any real 
crash in current callers. The motivation came from the v1 review 
discussion [1], where it was suggested that a NULL check in 
fastrpc_buf_free() would allow simplifying some of the caller paths.

[1]https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
> 
>> And it was pointed out in the v1 patch discussion that this change was
>> needed:
>> https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@oss.qualcomm.com/
> 
> Were the checks removed from the caller side like was asked for?
Currently, I have placed the check inside the API and removed all the 
checks outside the API.
> 
> Also, your changelog makes it sound like this is a real bugfix for
> something, when it is not at all, which is what I object to the most.
> Don't make scary changelogs for things that are not actually happening.
You are correct, I will modify the commit text that caused the 
misunderstanding.
> 
> thanks,
> 
> greg k-h
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Dmitry Baryshkov 3 weeks, 3 days ago 
On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> 
> The fastrpc_buf_free function currently does not handle the case where
> the input buffer pointer (buf) is NULL. This can lead to a null pointer
> dereference, causing a crash or undefined behavior when the function
> attempts to access members of the buf structure. Add a NULL check to
> ensure safe handling of NULL pointers and prevent potential crashes.

When does it happen? Do you have a backtrace or is it a safety coding?
Do you pass NULL buffer pointers to the function?

> 
> Fixes: c68cfb718c8f9 ("misc: fastrpc: Add support for context Invoke method")
> Cc: stable@kernel.org
> Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
> ---
>  drivers/misc/fastrpc.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 

-- 
With best wishes
Dmitry
Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
Posted by Jianping 1 week ago 

On 1/16/2026 4:43 AM, Dmitry Baryshkov wrote:
> On Thu, Jan 15, 2026 at 04:28:48PM +0800, Jianping Li wrote:
>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>
>> The fastrpc_buf_free function currently does not handle the case where
>> the input buffer pointer (buf) is NULL. This can lead to a null pointer
>> dereference, causing a crash or undefined behavior when the function
>> attempts to access members of the buf structure. Add a NULL check to
>> ensure safe handling of NULL pointers and prevent potential crashes.
> 
> When does it happen? Do you have a backtrace or is it a safety coding?
> Do you pass NULL buffer pointers to the function?
Thanks, Dmitry.
Yes, this change is mainly for safety‑coding purposes.

This is reachable on during remove/deinit sequences when a buffer was 
never allocated or allocation failed part‑way and cleanup proceeds.

It's a saftety coding: to eliminate NULL checks on the caller side, as 
we do in a lot of other kernel API.

At the same time, there is a possibility that this buffer passes NULL, 
and during verification, this can cause the kernel to crash.

The patch makes fastrpc_buf_free() NULL‑tolerant and simplifies callers 
by removing duplicated if (ptr) checks, reducing the chance of future 
omissions.
> 
>>
>> Fixes: c68cfb718c8f9 ("misc: fastrpc: Add support for context Invoke method")
>> Cc: stable@kernel.org
>> Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
>> ---
>>   drivers/misc/fastrpc.c | 12 ++++++------
>>   1 file changed, 6 insertions(+), 6 deletions(-)
>>
>

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.