All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Tom Van Braeckel <tomvanbraeckel@gmail.com>
Cc: rusty@rustcorp.com.au, lguest@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, fengguang.wu@intel.com, lkp@01.org
Subject: Re: [PATCH] lguest: explicitly setup /dev/lguest private_data
Date: Tue, 7 Apr 2015 10:36:16 +0200	[thread overview]
Message-ID: <20150407083616.GA14409@kroah.com> (raw)
In-Reply-To: <1428394698-16938-1-git-send-email-tomvanbraeckel@gmail.com>

On Tue, Apr 07, 2015 at 10:18:18AM +0200, Tom Van Braeckel wrote:
> The private_data member of the /dev/lguest device file is used to hold
> the current struct lguest and needs to be set to NULL to signify that
> no initialization has taken place.
> 
> We explicitly set it to NULL to be independent of whatever value the
> misc subsystem initializes it to.
> 
> Signed-off-by: Tom Van Braeckel <tomvanbraeckel@gmail.com>
> ---
> Backstory:
> ==========
> The misc subsystem used to initialize a file's private_data to point to
> the misc device when a driver had registered a custom open file
> operation and initialized it to NULL when a custom open file operation
> had *not* been provided.
> 
> This subtle quirk was confusing, to the point where kernel code
> registered *empty* file open operations to have private_data point to
> the misc device structure.
> 
> And it lead to bugs, where the addition or removal of a custom open
> file operation surprisingly changed the initial contents of a file's
> private_data structure.
> 
> The misc subsystem is currently underdoing changes to *always* set
> private_data to point to the misc device instead of only doing this
> when a custom open file operation has been registered.
> 
> Intel's 0day kernel testing robot discovered that the lguest driver
> depended on it implicitly being initialized to NULL, as Fengguang Wu
> reported. Thanks a lot for all the hard work!
> 
>  drivers/lguest/lguest_user.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)

I can take this through my char-misc tree, where this misc core change
was, if the lguest maintainer (i.e. Rusty) acks it.

Tom, thanks for tracking this down.

greg k-h

  parent reply	other threads:[~2015-04-07  8:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-06 12:10 [miscdevice] BUG: unable to handle kernel NULL pointer dereference at 00000028 Fengguang Wu
2015-04-06 12:10 ` Fengguang Wu
2015-04-07  8:18 ` [PATCH] lguest: explicitly setup /dev/lguest private_data Tom Van Braeckel
2015-04-07  8:34   ` Daniel Baluta
2015-04-07  8:34     ` Daniel Baluta
2015-04-07  8:55     ` Greg Kroah-Hartman
2015-04-07  8:36   ` Greg KH [this message]
2015-04-10  3:28     ` Rusty Russell

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=20150407083616.GA14409@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=lguest@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tomvanbraeckel@gmail.com \
    /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.