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 <[email protected]>
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/[email protected]/
And it was pointed out in the v1 patch discussion that this change was
needed:
https://lore.kernel.org/all/[email protected]/
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
