linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rand Deeb <rand.sec96@gmail.com>
To: James Dutton <james.dutton@gmail.com>
Cc: deeb.rand@confident.ru, jonas.gorski@gmail.com,
	khoroshilov@ispras.ru,  kvalo@kernel.org,
	linux-kernel@vger.kernel.org,  linux-wireless@vger.kernel.org,
	lvc-project@linuxtesting.org,
	 voskresenski.stanislav@confident.ru
Subject: Re: [PATCH v3] ssb: Fix potential NULL pointer dereference in ssb_device_uevent
Date: Fri, 8 Mar 2024 15:11:06 +0300	[thread overview]
Message-ID: <CAN8dotnMCQG+cUxKR_aq6=XxqMTh7KLDCpH1sOa6RqujKfYRgg@mail.gmail.com> (raw)
In-Reply-To: <CAAMvbhE53upfqfB=afJK9YAZUWFTBN8ripae0W+PUUXdwj4-kw@mail.gmail.com>

On Fri, Mar 8, 2024 at 4:05 AM James Dutton <james.dutton@gmail.com> wrote:
> The reason it is probably not a good design is what comes later.
> Another developer comes along and says I see a nice SUM(a, b);
> function that I would like to re-use in my new function I am adding.
> But that new developer introduces a bug whereby they have implemented
> their CHECK(a) wrongly which results in SUM(a, b) now being a security
> exploit point because of some very subtle bug in CHECK(a) that no one
> noticed initially.
> After a while, we might have ten functions that all re-use SUM(a, b)
> at which point it becomes too time consuming for someone to check all
> ten functions don't have bugs in their CHECK(a) steps.
> It is always easier for the safety checks to be done as close as
> possible to the potential exploit point (e.g. NULL pointer
> dereference) so that it catches all future cases of re-use of the
> function.
> For example, there exist today zero day exploits in the Linux wireless
> code that is due to the absence of these checks being done at the
> exploit point.
> The biggest problem with all this, is if I sutily (without wishing to
> give away that it is to fix a zero day exploit) submitted a patch to
> do an extra check in SUM(a, b) that I know prevents a zero day
> exploit, my patch would be rejected.

Hi James,

Thank you very much for your detailed and interesting interaction. In fact,
while I was writing the example, I expected such a comment :)

The example is just an explanation, do not take it literally, but it is
definitely better than the second method. Now, if the developer makes a
mistake using the function, this is possible, but this is not a convincing
reason to add redundant code everywhere. In addition mistakes could occur
in all scenarios.

I agree with you in general, but I will answer you in simple statements:

For this reason, modification permission should not be granted to anyone,
and for this reason there are reviewers and documentation. In the end,
Somehow, software engineering concepts are applied because this is one of
the most important projects and not a calculator project as homework for
the university.

Best Regards

  reply	other threads:[~2024-03-08 12:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 12:30 [PATCH v3] ssb: Fix potential NULL pointer dereference in ssb_device_uevent Rand Deeb
2024-03-06 15:54 ` Jeff Johnson
2024-03-06 19:51 ` Jonas Gorski
2024-03-07 13:41   ` Rand Deeb
2024-03-07 18:24     ` Michael Büsch
2024-03-07 21:19       ` Rand Deeb
2024-03-07 21:38         ` Michael Büsch
2024-03-07 22:02           ` James Dutton
2024-03-08  4:50             ` Michael Büsch
2024-03-07 23:29           ` Rand Deeb
2024-03-08  1:04             ` James Dutton
2024-03-08 12:11               ` Rand Deeb [this message]
2024-03-08  5:09             ` Michael Büsch
2024-03-08 11:36               ` Rand Deeb
2024-03-08 15:44                 ` Michael Büsch
2024-03-12 15:31 ` [v3] ssb: Fix potential NULL pointer dereference in ssb_device_uevent() Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN8dotnMCQG+cUxKR_aq6=XxqMTh7KLDCpH1sOa6RqujKfYRgg@mail.gmail.com' \
    --to=rand.sec96@gmail.com \
    --cc=deeb.rand@confident.ru \
    --cc=james.dutton@gmail.com \
    --cc=jonas.gorski@gmail.com \
    --cc=khoroshilov@ispras.ru \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=voskresenski.stanislav@confident.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).