All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Xiaole He <hexiaole1994@126.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	"brauner@kernel.org" <brauner@kernel.org>,
	"jack@suse.cz" <jack@suse.cz>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] fs/super.c: Add NULL check for type in iterate_supers_type
Date: Thu, 3 Apr 2025 03:47:56 +0100	[thread overview]
Message-ID: <20250403024756.GL2023217@ZenIV> (raw)
In-Reply-To: <4ee2fdcb.1854a.195f9828c86.Coremail.hexiaole1994@126.com>

On Thu, Apr 03, 2025 at 10:37:17AM +0800, Xiaole He wrote:
> Thank you for your feedback.
> While I acknowledge your points, I would like to clarify the rationale
> behind submitting this patch.
> During my experimentation with an external module interacting with the
> superblock, I utilized iterate_supers_type (from fs/super.c) as it is
> an exported symbol. However, I observed a potential vulnerability in
> its implementation: the type argument can be passed as NULL, leading
> to a null pointer dereference. To verify this, I deliberately triggered
> a scenario where type was set to NULL, resulting in the following dmesg
> output:

> After this observasion, I worry about if this vulnerability can cause
> the whole kernel crash if the type argument is passed by a
> unintentional NULL in the kernel code rather than in the external
> module.
> Thus I submitted the patch to address the missing null-check.
> Thank you for your review.

You do realize that passing it NULL as the second (function pointer) argument
would also oops, right?  Passing (void (*)(struct super_block *))kfree
there would do even more unpleasant things, etc.

Sure, it's exported - so's strlen().  While we are at it, checking just for
NULL is not the limit - what if the caller gives it ERR_PTR(...) as argument?

  parent reply	other threads:[~2025-04-03  2:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02  3:45 [PATCH v1] fs/super.c: Add NULL check for type in iterate_supers_type Xiaole He
2025-04-02 11:38 ` James Bottomley
     [not found]   ` <4ee2fdcb.1854a.195f9828c86.Coremail.hexiaole1994@126.com>
2025-04-03  2:47     ` Al Viro [this message]
     [not found]       ` <75a45193.18746.195f9a088c4.Coremail.hexiaole1994@126.com>
2025-04-03  3:50         ` Al Viro
2025-04-03  8:01 ` Christian Brauner

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=20250403024756.GL2023217@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=brauner@kernel.org \
    --cc=hexiaole1994@126.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.