linux-kernel - Re: [PATCH v3] ssb: Fix potential NULL pointer dereference in ssb_device

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: <CAAMvbhGmu5VtkA=KnxoHr=Fg_4=1yHFP_SERwKD_rxH=jpM1BA@mail.gmail.com>
Date: Thu, 7 Mar 2024 22:02:29 +0000
From: James Dutton <james.dutton@...il.com>
To: Michael Büsch <m@...s.ch>
Cc: Rand Deeb <rand.sec96@...il.com>, deeb.rand@...fident.ru, jonas.gorski@...il.com, 
	khoroshilov@...ras.ru, kvalo@...nel.org, linux-kernel@...r.kernel.org, 
	linux-wireless@...r.kernel.org, lvc-project@...uxtesting.org, 
	voskresenski.stanislav@...fident.ru
Subject: Re: [PATCH v3] ssb: Fix potential NULL pointer dereference in ssb_device_uevent

On Thu, 7 Mar 2024 at 21:39, Michael Büsch <m@...s.ch> wrote:
>
> On Fri,  8 Mar 2024 00:19:28 +0300
> Rand Deeb <rand.sec96@...il.com> wrote:
>
> > Defensive programming is typically applied when there's a potential risk,
>
> A NULL pointer dereference is Undefined Behavior.
> It can't get much worse in C.
>
> > If we adopt this
> > approach as a form of defensive programming, we'd find ourselves adding
> > similar conditions to numerous functions and parameters.
>
> Not at all.
> Your suggestion was about REMOVING a null pointer check.
> Not about adding one.
> I NAK-ed the REMOVAL of a null pointer check. Not the addition.
>

Hi,

This is an interesting discussion. Just to add my 2 cents.
If one does a NULL check after it has been previously dereferenced,
the compiler will totally remove the NULL check anyway, so although
the NULL check was in the source code, it will be absent from the
compiled code.
Re-arranging the NULL check to be before the dereference is fixing
that, but not necessarily in the way you expect.