Re: [PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check
On Mon, Jul 26, 2021 at 11:32:37AM +, tcs_kernel(腾讯云内核开发者) wrote: > yres and vyres can be controlled by user mode paramaters, and cause p->vrows > to become a negative value. While this value be passed to real_y function, > the ypos will be out of screen range. > This is an out-of-bounds write bug. > > > diff --git a/drivers/video/fbdev/core/fbcon.c > b/drivers/video/fbdev/core/fbcon.c > index 22bb3892f6bd..0970de46782f 100644 > --- a/drivers/video/fbdev/core/fbcon.c > +++ b/drivers/video/fbdev/core/fbcon.c > @@ -1956,11 +1956,12 @@ static void updatescrollmode(struct fbcon_display *p, > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual, >info->var.xres_virtual); > + int rows = vc->vc_rows; > > p->vrows = vyres/fh; > - if (yres > (fh * (vc->vc_rows + 1))) > - p->vrows -= (yres - (fh * vc->vc_rows)) / fh; > - if ((yres % fh) && (vyres % fh < yres % fh)) > + if ((yres > (fh * (rows + 1))) && (vyres >= (yres - (fh * rows))) && > p->vrows) > + p->vrows -= (yres - (fh * rows)) / fh; > + if ((yres % fh) && (vyres % fh < yres % fh) && p->vrows) > p->vrows--; > } > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch is malformed (tabs converted to spaces, linewrapped, etc.) and can not be applied. Please read the file, Documentation/email-clients.txt in order to fix this. - Your patch does not have a Signed-off-by: line. Please read the kernel file, Documentation/SubmittingPatches and resend it after adding that line. Note, the line needs to be in the body of the email, before the patch, not at the bottom of the patch or in the email signature. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Re: [Internet]Re: [PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check
On Tue, Jul 27, 2021 at 01:53:13AM +, tcs_kernel(腾讯云内核开发者) wrote: > yres and vyres can be controlled by user mode paramaters, and cause p->vrows > to become a negative value. While this value be passed to real_y function, > the ypos will be out of screen range. > This is an out-of-bounds write bug. > I think updatescrollmode is the right place to validate values supplied by a > user ioctl, because only here makes --operation,and 0 is a legal value before > that. Please wrap your changelog text. > > Signed-off-by: Tencent Cloud System [email protected] That is not the name of a person :( And the format isn't correct, so there's nothing we can do with this patch, and the patch itself is corrupted and could not be applied :( Also, what about checking these values earlier? How can the value be 0 earlier and be acceptable? Putting bounds on the user-provided values would be much easier, right? thanks, greg k-h
Re: [PATCH] Adjust analogix chip driver location
On Wed, Jun 26, 2019 at 10:44:38AM +, Xin Ji wrote: > Move analogix chip ANX78XX bridge driver into "analogix" directory. > > Signed-off-by: Xin Ji > --- > drivers/gpu/drm/bridge/Kconfig | 10 - > drivers/gpu/drm/bridge/Makefile|3 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 1485 > > drivers/gpu/drm/bridge/analogix-anx78xx.h | 710 -- > drivers/gpu/drm/bridge/analogix/Kconfig| 10 + > drivers/gpu/drm/bridge/analogix/Makefile |2 + > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 1485 > > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 710 ++ > 8 files changed, 2208 insertions(+), 2207 deletions(-) > delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.c > delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h 'git format-patch -M' is usually a lot better to use when moving files around, as it shows you only any changes in the files, not a huge delete/add cycle. thanks, greg k-h ___ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] usb: core:hub.c: do not print error log on -enomem
On Wed, Nov 30, 2016 at 11:40:28AM +, Atul Raj wrote: > changes in v2 > - added braces as suggested. Why is this here? > > drivers/usb/core/hub.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) No signed off? You didn't cc: linux-usb at vger? Come on, please step back and redo this properly, this isn't fun... greg k-h
[PATCH] usb:hub: readibility and consistency in coding style
On Wed, Nov 30, 2016 at 11:51:39AM +, Atul Raj wrote: > It is suggested to keep braces if there is a comment in if case as > comment also takes a line. > --- > drivers/usb/core/hub.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Ok, this is getting to be a joke. Take a few days off, relax, then try to send a patch that works to yourself first, and run it through scripts/checkpatch.pl to verify that it really is correct. Hint, this one isn't at all. Then, maybe you should start doing some work on drivers/staging/ first, which is where new developers should start out to work out all of these issues so you don't bother the other developers who are working on adding new features and fixing bugs. Also, why are you including a ton of people who have nothing to do with usb patches on this one? good luck, greg k-h
[PATCH] usb:hub: readibility and consistency in coding style
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Nov 30, 2016 at 12:35:21PM +, Atul Raj wrote: > Hi Greg, > > I am so happy to get a mail from you and I am really sorry Greg that I > disappointed you. > I will take utmost care in future. > I will send you correct patch in sometime. > for your ques > "Also, why are you including a ton of people who have nothing to do with > usb patches on this one?" > > I got the name of people from get_maintainer.pl When using get_maintainer.pl on this patch it does not include the dri-devel list, so I don't think you used it correctly. > from now I will include only you. > is it ok?? No, do it correctly. > one more thing in another mail you replied to me as > On Wed, Nov 30, 2016 at 11:40:28AM +, Atul Raj wrote: > > changes in v2 > > - added braces as suggested. > > Why is this here? > > > > > drivers/usb/core/hub.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > do you disagree with viresh comment of braces??? I disagree that this is a valid changelog comment, please read Documentation/SubmittingPatches for the correct way to do this. Again, if you don't have experience doing this, please work in the drivers/staging/ directory first, not in the "core" kernel. thanks, greg k-h
[PATCH] usb: host: replace symbolic permission with octal
On Wed, Nov 30, 2016 at 01:49:02PM +, Amit Kumar Kushwaha wrote: > This patch handles warning message for preferring octal > permissions over Symbolic permission for module parameter That makes no sense at all. What warning message? Build time? Run time? Please do cleanup patches on drivers/staging/ until you know how to do them, don't start on the "core" kernel, as you will just annoy maintainers (hint, you cc:ed too many people...) good luck! greg k-h
Patch "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S" has been added to the 3.5-stable tree
This is a note to let you know that I've just added the patch titled
drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
to the 3.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-add-edid_quirk_force_reduced_blanking-for-asus-vw222s.patch
and it can be found in the queue-3.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b Mon Sep 17 00:00:00 2001
From: Paul Menzel
Date: Wed, 8 Aug 2012 23:12:19 +0200
Subject: drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
From: Paul Menzel
commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.
Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.
In commit bc42aabc [2]
commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson
Date: Wed May 23 16:26:54 2012 -0400
drm/edid/quirks: ViewSonic VA2026w
Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.
All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.
Please note that this monitor only has a VGA (D-Sub) connector [1].
[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel
Cc:
Cc: Adam Jackson
Cc: Ian Pilcher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_edid.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
} edid_quirk_list[] = {
+ /* ASUS VW222S */
+ { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
Patches currently in stable-queue which might be from paulepanter at
users.sourceforge.net are
queue-3.5/drm-add-edid_quirk_force_reduced_blanking-for-asus-vw222s.patch
Patch "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
0014-drm-Add-EDID_QUIRK_FORCE_REDUCED_BLANKING-for-ASUS-V.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 31d04b5fa45264da10750fc7f526d0e65f894a29 Mon Sep 17 00:00:00 2001
From: Paul Menzel
Date: Wed, 8 Aug 2012 23:12:19 +0200
Subject: drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
From: Paul Menzel
commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.
Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.
In commit bc42aabc [2]
commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson
Date: Wed May 23 16:26:54 2012 -0400
drm/edid/quirks: ViewSonic VA2026w
Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.
All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.
Please note that this monitor only has a VGA (D-Sub) connector [1].
[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel
Cc:
Cc: Adam Jackson
Cc: Ian Pilcher
Signed-off-by: Dave Airlie
Signed-off-by: Julien Cristau
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_edid.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
} edid_quirk_list[] = {
+ /* ASUS VW222S */
+ { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
Patches currently in stable-queue which might be from paulepanter at
users.sourceforge.net are
queue-3.4/0014-drm-Add-EDID_QUIRK_FORCE_REDUCED_BLANKING-for-ASUS-V.patch
FAILED: patch "[PATCH] drm/i915: make compact dma scatter lists creation work with" failed to apply to 3.10-stable tree
The patch below does not apply to the 3.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .
thanks,
greg k-h
-- original commit in Linus's tree --
>From 1625e7e549c50fb57a1e1ab1cb0f5735c84c9029 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Mon, 24 Jun 2013 11:47:48 -0400
Subject: [PATCH] drm/i915: make compact dma scatter lists creation work with
SWIOTLB backend.
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") makes
certain assumptions about the under laying DMA API that are not always
correct.
On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup
I see:
[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28
Bit of debugging traced it down to dma_map_sg failing (in
i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB).
That unfortunately are sizes that the SWIOTLB is incapable of handling -
the maximum it can handle is a an entry of 512KB of virtual contiguous
memory for its bounce buffer. (See IO_TLB_SEGSIZE).
Previous to the above mention git commit the SG entries were of 4KB, and
the code introduced by above git commit squashed the CPU contiguous PFNs
in one big virtual address provided to DMA API.
This patch is a simple semi-revert - were we emulate the old behavior
if we detect that SWIOTLB is online. If it is not online then we continue
on with the new compact scatter gather mechanism.
An alternative solution would be for the the '.get_pages' and the
i915_gem_gtt_prepare_object to retry with smaller max gap of the
amount of PFNs that can be combined together - but with this issue
discovered during rc7 that might be too risky.
Reported-and-Tested-by: Konrad Rzeszutek Wilk
CC: Chris Wilson
CC: Imre Deak
CC: Daniel Vetter
CC: David Airlie
CC:
Signed-off-by: Konrad Rzeszutek Wilk
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a6178bac..e31eeb1d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1802,7 +1802,14 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
gfp |= __GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD;
gfp &= ~(__GFP_IO | __GFP_WAIT);
}
-
+#ifdef CONFIG_SWIOTLB
+ if (swiotlb_nr_tbl()) {
+ st->nents++;
+ sg_set_page(sg, page, PAGE_SIZE, 0);
+ sg = sg_next(sg);
+ continue;
+ }
+#endif
if (!i || page_to_pfn(page) != last_pfn + 1) {
if (i)
sg = sg_next(sg);
@@ -1813,8 +1820,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
}
last_pfn = page_to_pfn(page);
}
-
- sg_mark_end(sg);
+#ifdef CONFIG_SWIOTLB
+ if (!swiotlb_nr_tbl())
+#endif
+ sg_mark_end(sg);
obj->pages = st;
if (i915_gem_object_needs_bit17_swizzle(obj))
Re: [PATCH v9 2/9] mei: late_bind: add late binding component driver
On Fri, Sep 12, 2025 at 12:19:21AM -0500, Lucas De Marchi wrote:
> On Tue, Sep 09, 2025 at 09:43:02AM -0500, Lucas De Marchi wrote:
> > On Tue, Sep 09, 2025 at 04:50:41AM +, Usyskin, Alexander wrote:
> > > > > +static int mei_lb_component_match(struct device *dev, int
> > > > > subcomponent,
> > > > > + void *data)
> > > > > +{
> > > > > + /*
> > > > > + * This function checks if requester is Intel
> > > > > %PCI_CLASS_DISPLAY_VGA
> > > > or
> > > > > + * %PCI_CLASS_DISPLAY_OTHER device, and checks if the requester
> > > > > is
> > > > the
> > > > > + * grand parent of mei_if i.e. late bind MEI device
> > > > > + */
> > > > > + struct device *base = data;
> > > > > + struct pci_dev *pdev;
> > > > > +
> > > > > + if (!dev)
> > > > > + return 0;
> > > > > +
> > > > > + if (!dev_is_pci(dev))
> > > > > + return 0;
> > > > > +
> > > > > + pdev = to_pci_dev(dev);
> > > > > +
> > > > > + if (pdev->vendor != PCI_VENDOR_ID_INTEL)
> > > > > + return 0;
> > > > > +
> > > > > + if (pdev->class != (PCI_CLASS_DISPLAY_VGA << 8) &&
> > > > > + pdev->class != (PCI_CLASS_DISPLAY_OTHER << 8))
> > > >
> > > > this doesn't seem right, we should allow other PCI classes. AFAICS this
> > > > check could just be removed and just leave the INTEL_COMPONENT_LB below
> > > > to protect for component match
> > > >
> > > > Lucas De Marchi
> > > >
> > >
> > > The subcomponent is unique only in its own instance of the component
> > > framework.
> > > Or I'm wrong here?
> > > We have to ensure that we have Intel display device, not any other device
> > > to
> > > subcomponent check to work correctly.
> >
> > We are matching by child-parent relationship + the component id. So you
> > have both the mei device and another pci device that added that specific
> > subcomponent and both need to have a common parent. Thinking about
> > another device that would match the parent-child relationship: audio,
> > but audio doesn't add that.
> >
> > what scenario would cause a false match that I'm not seeing?
>
> so, I doesn't seem it would fail any, but it's fine as a sanity check.
> This is in fact very similar to mei_pxp_component_match(). If we are
> going to remove the display check, it could be done later on top, making
> sure not to match what it shouldn't.
>
> So, this looks good to me. I tested this on a Battlemage card
> it's correclty loading the firmware:
>
> xe :03:00.0: [drm:xe_late_bind_init [xe]] Request late binding
> firmware xe/fan_control_8086_e20b_8086_1100.bin
> xe :03:00.0: [drm] Using fan_control firmware from
> xe/fan_control_8086_e20b_8086_1100.bin version 203.0.0.0
> ...
> mei_lb xe.mei-gscfi.768-e2c2afa2-3817-4d19-9d95-06b16b588a5d: bound
> :03:00.0 (ops xe_late_bind_component_ops [xe])
> xe :03:00.0: [drm:xe_late_bind_work [xe]] Load fan_control firmware
> xe :03:00.0: [drm:xe_late_bind_work [xe]] Load fan_control firmware
> successful
>
>
> Reviewed-by: Lucas De Marchi
>
> Greg, does this look ok to you now for us to merge through drm?
No objection from me:
Acked-by: Greg Kroah-Hartman
