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 <[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.
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
