Re: [PATCH v2 1/4] misc: fastrpc: Add NULL check to fastrpc_buf_free to prevent crash
From: Jianping
Date: Tue Feb 03 2026 - 06:01:13 EST
On 2/2/2026 4:41 PM, Greg KH wrote:
On Mon, Feb 02, 2026 at 03:13:10PM +0800, Jianping wrote: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.
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@xxxxxxxxxxxxxxxx>
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.
[1]https://lore.kernel.org/all/c80c48a1-f1b6-4520-9d7c-3a83915c7717@xxxxxxxxxxxxxxxx/
Currently, I have placed the check inside the API and removed all the checks outside the 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@xxxxxxxxxxxxxxxx/
Were the checks removed from the caller side like was asked for?
You are correct, I will modify the commit text that caused the misunderstanding.
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