netdev - Re: [PATCH 1/6] can: esd_usb: Fix possible calls to kfree() with NULL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250817160200.76467a18@pumpkin>
Date: Sun, 17 Aug 2025 16:02:00 +0100
From: David Laight <david.laight.linux@...il.com>
To: Stefan Mätje <stefan.maetje@....eu>
Cc: "vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>,
 "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
 "mkl@...gutronix.de" <mkl@...gutronix.de>, Frank Jungclaus
 <frank.jungclaus@....eu>, "mailhol.vincent@...adoo.fr"
 <mailhol.vincent@...adoo.fr>, socketcan <socketcan@....eu>,
 "horms@...nel.org" <horms@...nel.org>, "socketcan@...tkopp.net"
 <socketcan@...tkopp.net>, "olivier@...rie.be" <olivier@...rie.be>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/6] can: esd_usb: Fix possible calls to kfree() with
 NULL

On Fri, 15 Aug 2025 14:57:44 +0000
Stefan Mätje <stefan.maetje@....eu> wrote:

> Am Dienstag, dem 12.08.2025 um 13:33 +0100 schrieb Vadim Fedorenko:
> > On 11/08/2025 22:06, Stefan MÃ¤tje wrote:  
> > > In esd_usb_start() kfree() is called with the msg variable even if the
> > > allocation of *msg failed.  
> > 
> > But kfree() works fine with NULL pointers, have you seen any real issues
> > with this code?  
> 
> Hello Vadim,
> 
> I've not seen real problems with this code. And when I posted the patch I
> knew that kfree() can cope with NULL pointers. But in any case calling a
> *free() function with a NULL pointer sends shivers over my spine and I
> want to avoid to stumble over this again and again.

The only time it is worth the check in the caller is the case where it
is normal for the pointer to be NULL.

But for an error exit it is safer to have one exit path that tidies everything
up rather than lots of them where there is the opportunity to exit via the
wrong one.

	David