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