All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Peilin Ye <yepeilin.cs@gmail.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
Date: Wed, 30 Sep 2020 13:52:11 +0200	[thread overview]
Message-ID: <20200930115211.GC1603625@kroah.com> (raw)
In-Reply-To: <CAKMK7uFzWZgs4rvqSXqn_ifr8utG_rNw54+y6CWjdV=Epak-iQ@mail.gmail.com>

On Wed, Sep 30, 2020 at 01:25:14PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> >
> > On Wed, Sep 30, 2020 at 11:53:17AM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> > > > On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> > > > > > Ah, and speaking of built-in fonts, see fbcon_startup():
> > > > > >
> > > > > >         /* Setup default font */
> > > > > >                 [...]
> > > > > >                 vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */
> > > > > >                             ^^^^^^^^^^^^^^^
> > > > > >
> > > > > > This is because find_font() and get_default_font() return a `struct
> > > > > > font_desc *`, but `struct font_desc` doesn't contain `charcount`. I
> > > > > > think we also need to add a `charcount` field to `struct font_desc`.
> > > > >
> > > > > Hm yeah ... I guess maybe struct font_desc should be the starting
> > > > > point for the kernel internal font structure. It's at least there
> > > > > already ...
> > > >
> > > > I see, that will also make handling built-in fonts much easier!
> > >
> > > I think the only downside with starting with font_desc as the internal
> > > font represenation is that there's a few fields we don't need/have for
> > > userspace fonts (like the id/name stuff). So any helpers to e.g. print out
> > > font information need to make sure they don't trip over that
> > >
> > > But otherwise I don't see a problem with this, I think.
> >
> > Yes, and built-in fonts don't use refcount. Or maybe we can let
> > find_font() and get_default_font() kmalloc() a copy of built-in font
> > data, then keep track of refcount for both user and built-in fonts, but
> > that will waste a few K of memory for each built-in font we use...
> 
> A possible trick for this would be to make sure built-in fonts start
> out with a refcount of 1. So never get freed. Plus maybe a check that
> if the name is set, then it's a built-in font and if we ever underflow
> the refcount we just WARN, but don't free anything.
> 
> Another trick would be kern_font_get/put wrappers (we'd want those
> anyway if the userspace fonts are refcounted) and if kern_font->name
> != NULL (i.e. built-in font with name) then we simply don't call
> kref_get/put.

Ick, don't do that, the first trick of having them start out with an
increased reference count is the best way here.  Makes the code simpler
and no special cases for the tear-down path.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Peilin Ye <yepeilin.cs@gmail.com>
Subject: Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
Date: Wed, 30 Sep 2020 11:52:11 +0000	[thread overview]
Message-ID: <20200930115211.GC1603625@kroah.com> (raw)
In-Reply-To: <CAKMK7uFzWZgs4rvqSXqn_ifr8utG_rNw54+y6CWjdV=Epak-iQ@mail.gmail.com>

On Wed, Sep 30, 2020 at 01:25:14PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> >
> > On Wed, Sep 30, 2020 at 11:53:17AM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> > > > On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> > > > > > Ah, and speaking of built-in fonts, see fbcon_startup():
> > > > > >
> > > > > >         /* Setup default font */
> > > > > >                 [...]
> > > > > >                 vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */
> > > > > >                             ^^^^^^^^^^^^^^^
> > > > > >
> > > > > > This is because find_font() and get_default_font() return a `struct
> > > > > > font_desc *`, but `struct font_desc` doesn't contain `charcount`. I
> > > > > > think we also need to add a `charcount` field to `struct font_desc`.
> > > > >
> > > > > Hm yeah ... I guess maybe struct font_desc should be the starting
> > > > > point for the kernel internal font structure. It's at least there
> > > > > already ...
> > > >
> > > > I see, that will also make handling built-in fonts much easier!
> > >
> > > I think the only downside with starting with font_desc as the internal
> > > font represenation is that there's a few fields we don't need/have for
> > > userspace fonts (like the id/name stuff). So any helpers to e.g. print out
> > > font information need to make sure they don't trip over that
> > >
> > > But otherwise I don't see a problem with this, I think.
> >
> > Yes, and built-in fonts don't use refcount. Or maybe we can let
> > find_font() and get_default_font() kmalloc() a copy of built-in font
> > data, then keep track of refcount for both user and built-in fonts, but
> > that will waste a few K of memory for each built-in font we use...
> 
> A possible trick for this would be to make sure built-in fonts start
> out with a refcount of 1. So never get freed. Plus maybe a check that
> if the name is set, then it's a built-in font and if we ever underflow
> the refcount we just WARN, but don't free anything.
> 
> Another trick would be kern_font_get/put wrappers (we'd want those
> anyway if the userspace fonts are refcounted) and if kern_font->name
> != NULL (i.e. built-in font with name) then we simply don't call
> kref_get/put.

Ick, don't do that, the first trick of having them start out with an
increased reference count is the best way here.  Makes the code simpler
and no special cases for the tear-down path.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Peilin Ye <yepeilin.cs@gmail.com>
Subject: Re: [Linux-kernel-mentees] [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
Date: Wed, 30 Sep 2020 13:52:11 +0200	[thread overview]
Message-ID: <20200930115211.GC1603625@kroah.com> (raw)
In-Reply-To: <CAKMK7uFzWZgs4rvqSXqn_ifr8utG_rNw54+y6CWjdV=Epak-iQ@mail.gmail.com>

On Wed, Sep 30, 2020 at 01:25:14PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> >
> > On Wed, Sep 30, 2020 at 11:53:17AM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> > > > On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> > > > > > Ah, and speaking of built-in fonts, see fbcon_startup():
> > > > > >
> > > > > >         /* Setup default font */
> > > > > >                 [...]
> > > > > >                 vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */
> > > > > >                             ^^^^^^^^^^^^^^^
> > > > > >
> > > > > > This is because find_font() and get_default_font() return a `struct
> > > > > > font_desc *`, but `struct font_desc` doesn't contain `charcount`. I
> > > > > > think we also need to add a `charcount` field to `struct font_desc`.
> > > > >
> > > > > Hm yeah ... I guess maybe struct font_desc should be the starting
> > > > > point for the kernel internal font structure. It's at least there
> > > > > already ...
> > > >
> > > > I see, that will also make handling built-in fonts much easier!
> > >
> > > I think the only downside with starting with font_desc as the internal
> > > font represenation is that there's a few fields we don't need/have for
> > > userspace fonts (like the id/name stuff). So any helpers to e.g. print out
> > > font information need to make sure they don't trip over that
> > >
> > > But otherwise I don't see a problem with this, I think.
> >
> > Yes, and built-in fonts don't use refcount. Or maybe we can let
> > find_font() and get_default_font() kmalloc() a copy of built-in font
> > data, then keep track of refcount for both user and built-in fonts, but
> > that will waste a few K of memory for each built-in font we use...
> 
> A possible trick for this would be to make sure built-in fonts start
> out with a refcount of 1. So never get freed. Plus maybe a check that
> if the name is set, then it's a built-in font and if we ever underflow
> the refcount we just WARN, but don't free anything.
> 
> Another trick would be kern_font_get/put wrappers (we'd want those
> anyway if the userspace fonts are refcounted) and if kern_font->name
> != NULL (i.e. built-in font with name) then we simply don't call
> kref_get/put.

Ick, don't do that, the first trick of having them start out with an
increased reference count is the best way here.  Makes the code simpler
and no special cases for the tear-down path.

thanks,

greg k-h
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Peilin Ye <yepeilin.cs@gmail.com>
Subject: Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
Date: Wed, 30 Sep 2020 13:52:11 +0200	[thread overview]
Message-ID: <20200930115211.GC1603625@kroah.com> (raw)
In-Reply-To: <CAKMK7uFzWZgs4rvqSXqn_ifr8utG_rNw54+y6CWjdV=Epak-iQ@mail.gmail.com>

On Wed, Sep 30, 2020 at 01:25:14PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> >
> > On Wed, Sep 30, 2020 at 11:53:17AM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> > > > On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> > > > > > Ah, and speaking of built-in fonts, see fbcon_startup():
> > > > > >
> > > > > >         /* Setup default font */
> > > > > >                 [...]
> > > > > >                 vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */
> > > > > >                             ^^^^^^^^^^^^^^^
> > > > > >
> > > > > > This is because find_font() and get_default_font() return a `struct
> > > > > > font_desc *`, but `struct font_desc` doesn't contain `charcount`. I
> > > > > > think we also need to add a `charcount` field to `struct font_desc`.
> > > > >
> > > > > Hm yeah ... I guess maybe struct font_desc should be the starting
> > > > > point for the kernel internal font structure. It's at least there
> > > > > already ...
> > > >
> > > > I see, that will also make handling built-in fonts much easier!
> > >
> > > I think the only downside with starting with font_desc as the internal
> > > font represenation is that there's a few fields we don't need/have for
> > > userspace fonts (like the id/name stuff). So any helpers to e.g. print out
> > > font information need to make sure they don't trip over that
> > >
> > > But otherwise I don't see a problem with this, I think.
> >
> > Yes, and built-in fonts don't use refcount. Or maybe we can let
> > find_font() and get_default_font() kmalloc() a copy of built-in font
> > data, then keep track of refcount for both user and built-in fonts, but
> > that will waste a few K of memory for each built-in font we use...
> 
> A possible trick for this would be to make sure built-in fonts start
> out with a refcount of 1. So never get freed. Plus maybe a check that
> if the name is set, then it's a built-in font and if we ever underflow
> the refcount we just WARN, but don't free anything.
> 
> Another trick would be kern_font_get/put wrappers (we'd want those
> anyway if the userspace fonts are refcounted) and if kern_font->name
> != NULL (i.e. built-in font with name) then we simply don't call
> kref_get/put.

Ick, don't do that, the first trick of having them start out with an
increased reference count is the best way here.  Makes the code simpler
and no special cases for the tear-down path.

thanks,

greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-09-30 11:52 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10  4:35 KASAN: global-out-of-bounds Read in fbcon_get_font syzbot
2019-12-10  4:35 ` syzbot
2019-12-10  4:35 ` syzbot
2020-01-01 17:40 ` syzbot
2020-01-01 17:40   ` syzbot
2020-01-01 17:40   ` syzbot
2020-09-24 13:38 ` [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers Peilin Ye
2020-09-24 13:38   ` Peilin Ye
2020-09-24 13:38   ` [Linux-kernel-mentees] " Peilin Ye
2020-09-24 13:38   ` Peilin Ye
2020-09-24 13:40   ` [PATCH 1/3] fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h Peilin Ye
2020-09-24 13:40     ` Peilin Ye
2020-09-24 13:40     ` [Linux-kernel-mentees] " Peilin Ye
2020-09-24 13:40     ` Peilin Ye
2020-09-24 13:42     ` [PATCH 2/3] Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts Peilin Ye
2020-09-24 13:42       ` Peilin Ye
2020-09-24 13:42       ` [Linux-kernel-mentees] " Peilin Ye
2020-09-24 13:42       ` Peilin Ye
2020-09-24 13:43       ` [PATCH 3/3] fbcon: Fix global-out-of-bounds read in fbcon_get_font() Peilin Ye
2020-09-24 13:43         ` Peilin Ye
2020-09-24 13:43         ` [Linux-kernel-mentees] " Peilin Ye
2020-09-24 13:43         ` Peilin Ye
2020-09-24 14:09   ` [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers Greg Kroah-Hartman
2020-09-24 14:09     ` Greg Kroah-Hartman
2020-09-24 14:09     ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-09-24 14:09     ` Greg Kroah-Hartman
2020-09-24 14:25     ` Peilin Ye
2020-09-24 14:25       ` Peilin Ye
2020-09-24 14:25       ` [Linux-kernel-mentees] " Peilin Ye
2020-09-24 14:25       ` Peilin Ye
2020-09-24 14:42     ` David Laight
2020-09-24 14:42       ` David Laight
2020-09-24 14:42       ` [Linux-kernel-mentees] " David Laight
2020-09-24 14:42       ` David Laight
2020-09-24 15:30       ` Peilin Ye
2020-09-24 15:30         ` Peilin Ye
2020-09-24 15:30         ` [Linux-kernel-mentees] " Peilin Ye
2020-09-24 15:30         ` Peilin Ye
2020-09-24 15:45         ` Dan Carpenter
2020-09-24 15:45           ` Dan Carpenter
2020-09-24 15:45           ` [Linux-kernel-mentees] " Dan Carpenter
2020-09-24 15:45           ` Dan Carpenter
2020-09-24 16:59           ` Peilin Ye
2020-09-24 16:59             ` Peilin Ye
2020-09-24 16:59             ` [Linux-kernel-mentees] " Peilin Ye
2020-09-24 16:59             ` Peilin Ye
2020-09-25  8:38     ` Daniel Vetter
2020-09-25  8:38       ` Daniel Vetter
2020-09-25  8:38       ` [Linux-kernel-mentees] " Daniel Vetter
2020-09-25  8:38       ` Daniel Vetter
2020-09-25  6:46   ` Jiri Slaby
2020-09-25  6:46     ` Jiri Slaby
2020-09-25  6:46     ` [Linux-kernel-mentees] " Jiri Slaby
2020-09-25  6:46     ` Jiri Slaby
2020-09-25 10:13     ` Peilin Ye
2020-09-25 10:13       ` Peilin Ye
2020-09-25 10:13       ` [Linux-kernel-mentees] " Peilin Ye
2020-09-25 10:13       ` Peilin Ye
2020-09-25 13:25       ` Daniel Vetter
2020-09-25 13:25         ` Daniel Vetter
2020-09-25 13:25         ` [Linux-kernel-mentees] " Daniel Vetter
2020-09-25 13:25         ` Daniel Vetter
2020-09-25 15:35         ` Peilin Ye
2020-09-25 15:35           ` Peilin Ye
2020-09-25 15:35           ` [Linux-kernel-mentees] " Peilin Ye
2020-09-25 15:35           ` Peilin Ye
2020-09-29  9:09           ` Daniel Vetter
2020-09-29  9:09             ` Daniel Vetter
2020-09-29  9:09             ` [Linux-kernel-mentees] " Daniel Vetter
2020-09-29  9:09             ` Daniel Vetter
2020-09-29  9:44             ` Peilin Ye
2020-09-29  9:44               ` Peilin Ye
2020-09-29  9:44               ` [Linux-kernel-mentees] " Peilin Ye
2020-09-29  9:44               ` Peilin Ye
2020-09-29 12:34         ` Peilin Ye
2020-09-29 12:34           ` Peilin Ye
2020-09-29 12:34           ` [Linux-kernel-mentees] " Peilin Ye
2020-09-29 12:34           ` Peilin Ye
2020-09-29 14:38           ` Daniel Vetter
2020-09-29 14:38             ` Daniel Vetter
2020-09-29 14:38             ` [Linux-kernel-mentees] " Daniel Vetter
2020-09-29 14:38             ` Daniel Vetter
2020-09-30  7:11             ` Peilin Ye
2020-09-30  7:11               ` Peilin Ye
2020-09-30  7:11               ` [Linux-kernel-mentees] " Peilin Ye
2020-09-30  7:11               ` Peilin Ye
2020-09-30  9:53               ` Daniel Vetter
2020-09-30  9:53                 ` Daniel Vetter
2020-09-30  9:53                 ` [Linux-kernel-mentees] " Daniel Vetter
2020-09-30  9:53                 ` Daniel Vetter
2020-09-30 10:55                 ` Peilin Ye
2020-09-30 10:55                   ` Peilin Ye
2020-09-30 10:55                   ` [Linux-kernel-mentees] " Peilin Ye
2020-09-30 10:55                   ` Peilin Ye
2020-09-30 11:25                   ` Daniel Vetter
2020-09-30 11:25                     ` Daniel Vetter
2020-09-30 11:25                     ` [Linux-kernel-mentees] " Daniel Vetter
2020-09-30 11:25                     ` Daniel Vetter
2020-09-30 11:52                     ` Greg Kroah-Hartman [this message]
2020-09-30 11:52                       ` Greg Kroah-Hartman
2020-09-30 11:52                       ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-09-30 11:52                       ` Greg Kroah-Hartman
2020-09-30 12:58                       ` Peilin Ye
2020-09-30 12:58                         ` Peilin Ye
2020-09-30 12:58                         ` [Linux-kernel-mentees] " Peilin Ye
2020-09-30 12:58                         ` Peilin Ye
2020-09-30  5:26           ` Jiri Slaby
2020-09-30  5:26             ` Jiri Slaby
2020-09-30  5:26             ` [Linux-kernel-mentees] " Jiri Slaby
2020-09-30  5:26             ` Jiri Slaby
2020-09-30  7:16             ` Peilin Ye
2020-09-30  7:16               ` Peilin Ye
2020-09-30  7:16               ` [Linux-kernel-mentees] " Peilin Ye
2020-09-30  7:16               ` Peilin Ye

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=20200930115211.GC1603625@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yepeilin.cs@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.