From: Peilin Ye <yepeilin.cs@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: daniel.vetter@ffwll.ch, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, gregkh@linuxfoundation.org,
Lee Jones <lee.jones@linaro.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/1] Fonts: font_acorn_8x8: Replace discarded const qualifier
Date: Mon, 2 Nov 2020 11:12:03 -0500 [thread overview]
Message-ID: <20201102161203.GA1561792@PWN> (raw)
In-Reply-To: <20201102102343.GK1551@shell.armlinux.org.uk>
Hi Russell,
On Mon, Nov 02, 2020 at 10:23:43AM +0000, Russell King - ARM Linux admin wrote:
> On Sun, Nov 01, 2020 at 01:11:22PM +0000, Lee Jones wrote:
> > On Sat, 31 Oct 2020, Russell King - ARM Linux admin wrote:
> >
> > > On Fri, Oct 30, 2020 at 06:18:22PM +0000, Lee Jones wrote:
> > > > Commit 09e5b3fd5672 ("Fonts: Support FONT_EXTRA_WORDS macros for
> > >
> > > Your commit ID does not exist in mainline kernels, which makes this
> > > confusing. The commit ID you should be using is 6735b4632def.
> >
> > Ah yes, quite right. That is the ID from android-3.18 where this
> > issue was first seen and fixed against. I will fix it up for
> > Mainline.
> >
> > Does the fix look okay to you though Russell?
>
> Frankly, I don't know. Looking at the commit itself, it looks safe,
> but it depends what this "extra" data is being used for. From what
> I can see, the commit in question just adds the additional opaque
> data as a member named "extra", and one is left to guess what it's
> use as.
Thank you very much for looking into this. I apologize for the trouble
and confusion it has caused.
The motivation behind this commit, and commit 5af08640795b ("fbcon: Fix
global-out-of-bounds read in fbcon_get_font()") was to fix a decades-old
out-of-bounds access bug in the framebuffer layer.
However the framebuffer layer is doing bounds checking in a very strange
way, by hiding the buffer length before the buffer, then access it using
a negative-indexing macro:
#define FNTSIZE(fd) (((int *)(fd))[-2])
Other "extra" (so-called by the framebuffer layer) fields include:
#define REFCOUNT(fd) (((int *)(fd))[-1])
#define FNTCHARCNT(fd) (((int *)(fd))[-3])
#define FNTSUM(fd) (((int *)(fd))[-4])
...representing reference count, character count and checksum,
respectively.
The commit in question (6735b4632def) prepends the buffer length to each
of the built-in font buffers, so other functions in the framebuffer
layer can use FNTSIZE() on them. 5af08640795b uses it to fix that
out-of-bounds bug.
> I'd have thought a small structure with named members would have
> been the minimum given our standards for in-kernel code.
Yes, this is a temporary bug fix, and is far from satisfactory. We are
trying to replace these magic macros using a structure with properly
named members. It is taking more time than I imagined, but one day this
temporary fix will disappear from the kernel, I hope.
> Why was the "const" dropped in the first place? Does this "extra"
> member get written to somewhere?
No, I will try to come up with a solution without these fields being
writable.
> So, sorry, no idea. This looks to me like a very unsatisfactory
> commit, and probably something that got a very poor review.
I hope this helps explain it.
Again, I apologize for all the troubles. I will do more thorough testing
and practice writing a commit message. Thank you!
Sincerely,
Peilin Ye
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Peilin Ye <yepeilin.cs@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Lee Jones <lee.jones@linaro.org>,
daniel.vetter@ffwll.ch, gregkh@linuxfoundation.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/1] Fonts: font_acorn_8x8: Replace discarded const qualifier
Date: Mon, 2 Nov 2020 11:12:03 -0500 [thread overview]
Message-ID: <20201102161203.GA1561792@PWN> (raw)
In-Reply-To: <20201102102343.GK1551@shell.armlinux.org.uk>
Hi Russell,
On Mon, Nov 02, 2020 at 10:23:43AM +0000, Russell King - ARM Linux admin wrote:
> On Sun, Nov 01, 2020 at 01:11:22PM +0000, Lee Jones wrote:
> > On Sat, 31 Oct 2020, Russell King - ARM Linux admin wrote:
> >
> > > On Fri, Oct 30, 2020 at 06:18:22PM +0000, Lee Jones wrote:
> > > > Commit 09e5b3fd5672 ("Fonts: Support FONT_EXTRA_WORDS macros for
> > >
> > > Your commit ID does not exist in mainline kernels, which makes this
> > > confusing. The commit ID you should be using is 6735b4632def.
> >
> > Ah yes, quite right. That is the ID from android-3.18 where this
> > issue was first seen and fixed against. I will fix it up for
> > Mainline.
> >
> > Does the fix look okay to you though Russell?
>
> Frankly, I don't know. Looking at the commit itself, it looks safe,
> but it depends what this "extra" data is being used for. From what
> I can see, the commit in question just adds the additional opaque
> data as a member named "extra", and one is left to guess what it's
> use as.
Thank you very much for looking into this. I apologize for the trouble
and confusion it has caused.
The motivation behind this commit, and commit 5af08640795b ("fbcon: Fix
global-out-of-bounds read in fbcon_get_font()") was to fix a decades-old
out-of-bounds access bug in the framebuffer layer.
However the framebuffer layer is doing bounds checking in a very strange
way, by hiding the buffer length before the buffer, then access it using
a negative-indexing macro:
#define FNTSIZE(fd) (((int *)(fd))[-2])
Other "extra" (so-called by the framebuffer layer) fields include:
#define REFCOUNT(fd) (((int *)(fd))[-1])
#define FNTCHARCNT(fd) (((int *)(fd))[-3])
#define FNTSUM(fd) (((int *)(fd))[-4])
...representing reference count, character count and checksum,
respectively.
The commit in question (6735b4632def) prepends the buffer length to each
of the built-in font buffers, so other functions in the framebuffer
layer can use FNTSIZE() on them. 5af08640795b uses it to fix that
out-of-bounds bug.
> I'd have thought a small structure with named members would have
> been the minimum given our standards for in-kernel code.
Yes, this is a temporary bug fix, and is far from satisfactory. We are
trying to replace these magic macros using a structure with properly
named members. It is taking more time than I imagined, but one day this
temporary fix will disappear from the kernel, I hope.
> Why was the "const" dropped in the first place? Does this "extra"
> member get written to somewhere?
No, I will try to come up with a solution without these fields being
writable.
> So, sorry, no idea. This looks to me like a very unsatisfactory
> commit, and probably something that got a very poor review.
I hope this helps explain it.
Again, I apologize for all the troubles. I will do more thorough testing
and practice writing a commit message. Thank you!
Sincerely,
Peilin Ye
next prev parent reply other threads:[~2020-11-02 16:23 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 18:18 [PATCH 1/1] Fonts: font_acorn_8x8: Replace discarded const qualifier Lee Jones
2020-10-30 18:18 ` Lee Jones
2020-10-31 5:09 ` Peilin Ye
2020-10-31 5:09 ` Peilin Ye
2020-10-31 10:27 ` Russell King - ARM Linux admin
2020-10-31 10:27 ` Russell King - ARM Linux admin
2020-11-01 13:11 ` Lee Jones
2020-11-01 13:11 ` Lee Jones
2020-11-02 10:23 ` Russell King - ARM Linux admin
2020-11-02 10:23 ` Russell King - ARM Linux admin
2020-11-02 10:30 ` Russell King - ARM Linux admin
2020-11-02 10:30 ` Russell King - ARM Linux admin
2020-11-02 16:12 ` Peilin Ye [this message]
2020-11-02 16:12 ` Peilin Ye
2020-11-02 10:56 ` Daniel Vetter
2020-11-02 10:56 ` Daniel Vetter
2020-11-02 11:09 ` Lee Jones
2020-11-02 11:09 ` Lee Jones
2020-11-02 11:18 ` Daniel Vetter
2020-11-02 11:18 ` Daniel Vetter
2020-11-02 11:30 ` Lee Jones
2020-11-02 11:30 ` Lee Jones
2020-11-02 14:50 ` Daniel Vetter
2020-11-02 14:50 ` Daniel Vetter
2020-11-02 16:17 ` Peilin Ye
2020-11-02 16:17 ` Peilin Ye
2020-11-02 16:24 ` Lee Jones
2020-11-02 16:24 ` Lee Jones
2020-11-02 16:25 ` Lee Jones
2020-11-02 16:25 ` Lee Jones
2020-11-02 16:34 ` Peilin Ye
2020-11-02 16:34 ` Peilin Ye
2020-11-02 18:32 ` [PATCH v2 1/1] Fonts: " Peilin Ye
2020-11-02 18:32 ` Peilin Ye
2020-11-03 8:53 ` Lee Jones
2020-11-03 8:53 ` Lee Jones
2020-11-03 8:58 ` Daniel Vetter
2020-11-03 8:58 ` Daniel Vetter
2020-11-03 9:15 ` Greg KH
2020-11-03 9:15 ` Greg KH
2020-11-03 9:52 ` Daniel Vetter
2020-11-03 9:52 ` Daniel Vetter
2020-11-03 10:55 ` Lee Jones
2020-11-03 10:55 ` Lee Jones
2020-11-03 11:42 ` Peilin Ye
2020-11-03 11:42 ` Peilin Ye
2020-11-07 5:19 ` Peilin Ye
2020-11-07 5:19 ` Peilin Ye
2020-11-07 15:36 ` Greg KH
2020-11-07 15:36 ` Greg KH
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=20201102161203.GA1561792@PWN \
--to=yepeilin.cs@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=gregkh@linuxfoundation.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=stable@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.