<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/video, branch v5.4.244</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>fbdev: udlfb: Fix endpoint check</title>
<updated>2023-05-30T11:44:09+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2023-05-19T19:32:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1522dc58bff87af79461b96d90ec122e9e726004'/>
<id>1522dc58bff87af79461b96d90ec122e9e726004</id>
<content type='text'>
commit ed9de4ed39875706607fb08118a58344ae6c5f42 upstream.

The syzbot fuzzer detected a problem in the udlfb driver, caused by an
endpoint not having the expected type:

usb 1-1: Read EDID byte 0 failed: -71
usb 1-1: Unable to get valid EDID from device/display
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880
drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted
6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
04/28/2023
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
 &lt;TASK&gt;
 dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980
 dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315
 dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111
 dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743

The current approach for this issue failed to catch the problem
because it only checks for the existence of a bulk-OUT endpoint; it
doesn't check whether this endpoint is the one that the driver will
actually use.

We can fix the problem by instead checking that the endpoint used by
the driver does exist and is bulk-OUT.

Reported-and-tested-by: syzbot+0e22d63dcebb802b9bc8@syzkaller.appspotmail.com
Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
CC: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Fixes: aaf7dbe07385 ("video: fbdev: udlfb: properly check endpoint type")
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ed9de4ed39875706607fb08118a58344ae6c5f42 upstream.

The syzbot fuzzer detected a problem in the udlfb driver, caused by an
endpoint not having the expected type:

usb 1-1: Read EDID byte 0 failed: -71
usb 1-1: Unable to get valid EDID from device/display
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880
drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted
6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
04/28/2023
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
 &lt;TASK&gt;
 dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980
 dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315
 dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111
 dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743

The current approach for this issue failed to catch the problem
because it only checks for the existence of a bulk-OUT endpoint; it
doesn't check whether this endpoint is the one that the driver will
actually use.

We can fix the problem by instead checking that the endpoint used by
the driver does exist and is bulk-OUT.

Reported-and-tested-by: syzbot+0e22d63dcebb802b9bc8@syzkaller.appspotmail.com
Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
CC: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Fixes: aaf7dbe07385 ("video: fbdev: udlfb: properly check endpoint type")
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: au1200fb: Fix potential divide by zero</title>
<updated>2023-04-05T09:16:43+00:00</updated>
<author>
<name>Wei Chen</name>
<email>harperchen1110@gmail.com</email>
</author>
<published>2023-03-15T09:22:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=856fb74f601a7b510e83002d046d12cf19d48f85'/>
<id>856fb74f601a7b510e83002d046d12cf19d48f85</id>
<content type='text'>
[ Upstream commit 44a3b36b42acfc433aaaf526191dd12fbb919fdb ]

var-&gt;pixclock can be assigned to zero by user. Without
proper check, divide by zero would occur when invoking
macro PICOS2KHZ in au1200fb_fb_check_var.

Error out if var-&gt;pixclock is zero.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 44a3b36b42acfc433aaaf526191dd12fbb919fdb ]

var-&gt;pixclock can be assigned to zero by user. Without
proper check, divide by zero would occur when invoking
macro PICOS2KHZ in au1200fb_fb_check_var.

Error out if var-&gt;pixclock is zero.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: lxfb: Fix potential divide by zero</title>
<updated>2023-04-05T09:16:43+00:00</updated>
<author>
<name>Wei Chen</name>
<email>harperchen1110@gmail.com</email>
</author>
<published>2023-03-15T09:05:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=deef33c0810464ec69f2eeb8006958fc219597d1'/>
<id>deef33c0810464ec69f2eeb8006958fc219597d1</id>
<content type='text'>
[ Upstream commit 61ac4b86a4c047c20d5cb423ddd87496f14d9868 ]

var-&gt;pixclock can be assigned to zero by user. Without proper
check, divide by zero would occur in lx_set_clock.

Error out if var-&gt;pixclock is zero.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 61ac4b86a4c047c20d5cb423ddd87496f14d9868 ]

var-&gt;pixclock can be assigned to zero by user. Without proper
check, divide by zero would occur in lx_set_clock.

Error out if var-&gt;pixclock is zero.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: intelfb: Fix potential divide by zero</title>
<updated>2023-04-05T09:16:42+00:00</updated>
<author>
<name>Wei Chen</name>
<email>harperchen1110@gmail.com</email>
</author>
<published>2023-03-15T08:33:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4f5cc5ffa8c51cc315e523ad0a7078956e461045'/>
<id>4f5cc5ffa8c51cc315e523ad0a7078956e461045</id>
<content type='text'>
[ Upstream commit d823685486a3446d061fed7c7d2f80af984f119a ]

Variable var-&gt;pixclock is controlled by user and can be assigned
to zero. Without proper check, divide by zero would occur in
intelfbhw_validate_mode and intelfbhw_mode_to_hw.

Error out if var-&gt;pixclock is zero.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d823685486a3446d061fed7c7d2f80af984f119a ]

Variable var-&gt;pixclock is controlled by user and can be assigned
to zero. Without proper check, divide by zero would occur in
intelfbhw_validate_mode and intelfbhw_mode_to_hw.

Error out if var-&gt;pixclock is zero.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: nvidia: Fix potential divide by zero</title>
<updated>2023-04-05T09:16:42+00:00</updated>
<author>
<name>Wei Chen</name>
<email>harperchen1110@gmail.com</email>
</author>
<published>2023-03-15T07:18:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=868f247e47ef1346b706d17cbd104b367f60823b'/>
<id>868f247e47ef1346b706d17cbd104b367f60823b</id>
<content type='text'>
[ Upstream commit 92e2a00f2987483e1f9253625828622edd442e61 ]

variable var-&gt;pixclock can be set by user. In case it
equals to zero, divide by zero would occur in nvidiafb_set_par.

Similar crashes have happened in other fbdev drivers. There
is no check and modification on var-&gt;pixclock along the call
chain to nvidia_check_var and nvidiafb_set_par. We believe it
could also be triggered in driver nvidia from user site.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 92e2a00f2987483e1f9253625828622edd442e61 ]

variable var-&gt;pixclock can be set by user. In case it
equals to zero, divide by zero would occur in nvidiafb_set_par.

Similar crashes have happened in other fbdev drivers. There
is no check and modification on var-&gt;pixclock along the call
chain to nvidia_check_var and nvidiafb_set_par. We believe it
could also be triggered in driver nvidia from user site.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: tgafb: Fix potential divide by zero</title>
<updated>2023-04-05T09:16:42+00:00</updated>
<author>
<name>Wei Chen</name>
<email>harperchen1110@gmail.com</email>
</author>
<published>2023-03-07T13:08:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=521877bf26513d6d0da70ae752029f1fa3368a00'/>
<id>521877bf26513d6d0da70ae752029f1fa3368a00</id>
<content type='text'>
[ Upstream commit f90bd245de82c095187d8c2cabb8b488a39eaecc ]

fb_set_var would by called when user invokes ioctl with cmd
FBIOPUT_VSCREENINFO. User-provided data would finally reach
tgafb_check_var. In case var-&gt;pixclock is assigned to zero,
divide by zero would occur when checking whether reciprocal
of var-&gt;pixclock is too high.

Similar crashes have happened in other fbdev drivers. There
is no check and modification on var-&gt;pixclock along the call
chain to tgafb_check_var. We believe it could also be triggered
in driver tgafb from user site.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f90bd245de82c095187d8c2cabb8b488a39eaecc ]

fb_set_var would by called when user invokes ioctl with cmd
FBIOPUT_VSCREENINFO. User-provided data would finally reach
tgafb_check_var. In case var-&gt;pixclock is assigned to zero,
divide by zero would occur when checking whether reciprocal
of var-&gt;pixclock is too high.

Similar crashes have happened in other fbdev drivers. There
is no check and modification on var-&gt;pixclock along the call
chain to tgafb_check_var. We believe it could also be triggered
in driver tgafb from user site.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: stifb: Provide valid pixelclock and add fb_check_var() checks</title>
<updated>2023-03-22T12:28:09+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2023-03-16T10:38:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a976ff743eb1d6897dcc4e53516fe2e1167aa804'/>
<id>a976ff743eb1d6897dcc4e53516fe2e1167aa804</id>
<content type='text'>
commit 203873a535d627c668f293be0cb73e26c30f9cc7 upstream.

Find a valid modeline depending on the machine graphic card
configuration and add the fb_check_var() function to validate
Xorg provided graphics settings.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 203873a535d627c668f293be0cb73e26c30f9cc7 upstream.

Find a valid modeline depending on the machine graphic card
configuration and add the fb_check_var() function to validate
Xorg provided graphics settings.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: smscufx: fix error handling code in ufx_usb_probe</title>
<updated>2023-02-22T11:50:29+00:00</updated>
<author>
<name>Dongliang Mu</name>
<email>dzm91@hust.edu.cn</email>
</author>
<published>2022-11-11T05:49:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3b3d3127f5b4291ae4caaf50f7b66089ad600480'/>
<id>3b3d3127f5b4291ae4caaf50f7b66089ad600480</id>
<content type='text'>
commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 upstream.

The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.

My local syzkaller reports a memory leak bug:

memory leak in ufx_usb_probe

BUG: memory leak
unreferenced object 0xffff88802f879580 (size 128):
  comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
  hex dump (first 32 bytes):
    80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff  .!|.............
    00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00  ................
  backtrace:
    [&lt;ffffffff814c99a0&gt;] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
    [&lt;ffffffff824d219c&gt;] kmalloc include/linux/slab.h:553 [inline]
    [&lt;ffffffff824d219c&gt;] kzalloc include/linux/slab.h:689 [inline]
    [&lt;ffffffff824d219c&gt;] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline]
    [&lt;ffffffff824d219c&gt;] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655
    [&lt;ffffffff82d17927&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [&lt;ffffffff82712f0d&gt;] call_driver_probe drivers/base/dd.c:560 [inline]
    [&lt;ffffffff82712f0d&gt;] really_probe+0x12d/0x390 drivers/base/dd.c:639
    [&lt;ffffffff8271322f&gt;] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
    [&lt;ffffffff827132da&gt;] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
    [&lt;ffffffff82713c27&gt;] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
    [&lt;ffffffff82710137&gt;] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [&lt;ffffffff827136b5&gt;] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
    [&lt;ffffffff82711d36&gt;] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
    [&lt;ffffffff8270e242&gt;] device_add+0x642/0xdc0 drivers/base/core.c:3517
    [&lt;ffffffff82d14d5f&gt;] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170
    [&lt;ffffffff82d2576c&gt;] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
    [&lt;ffffffff82d16ffc&gt;] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
    [&lt;ffffffff82712f0d&gt;] call_driver_probe drivers/base/dd.c:560 [inline]
    [&lt;ffffffff82712f0d&gt;] really_probe+0x12d/0x390 drivers/base/dd.c:639
    [&lt;ffffffff8271322f&gt;] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778

Fix this bug by rewriting the error handling code in ufx_usb_probe.

Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Tested-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Signed-off-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b76449ee75e21acfe9fa4c653d8598f191ed7d68 upstream.

The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.

My local syzkaller reports a memory leak bug:

memory leak in ufx_usb_probe

BUG: memory leak
unreferenced object 0xffff88802f879580 (size 128):
  comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
  hex dump (first 32 bytes):
    80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff  .!|.............
    00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00  ................
  backtrace:
    [&lt;ffffffff814c99a0&gt;] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
    [&lt;ffffffff824d219c&gt;] kmalloc include/linux/slab.h:553 [inline]
    [&lt;ffffffff824d219c&gt;] kzalloc include/linux/slab.h:689 [inline]
    [&lt;ffffffff824d219c&gt;] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline]
    [&lt;ffffffff824d219c&gt;] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655
    [&lt;ffffffff82d17927&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [&lt;ffffffff82712f0d&gt;] call_driver_probe drivers/base/dd.c:560 [inline]
    [&lt;ffffffff82712f0d&gt;] really_probe+0x12d/0x390 drivers/base/dd.c:639
    [&lt;ffffffff8271322f&gt;] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
    [&lt;ffffffff827132da&gt;] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
    [&lt;ffffffff82713c27&gt;] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
    [&lt;ffffffff82710137&gt;] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [&lt;ffffffff827136b5&gt;] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
    [&lt;ffffffff82711d36&gt;] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
    [&lt;ffffffff8270e242&gt;] device_add+0x642/0xdc0 drivers/base/core.c:3517
    [&lt;ffffffff82d14d5f&gt;] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170
    [&lt;ffffffff82d2576c&gt;] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
    [&lt;ffffffff82d16ffc&gt;] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
    [&lt;ffffffff82712f0d&gt;] call_driver_probe drivers/base/dd.c:560 [inline]
    [&lt;ffffffff82712f0d&gt;] really_probe+0x12d/0x390 drivers/base/dd.c:639
    [&lt;ffffffff8271322f&gt;] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778

Fix this bug by rewriting the error handling code in ufx_usb_probe.

Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Tested-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Signed-off-by: Dongliang Mu &lt;dzm91@hust.edu.cn&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbcon: Check font dimension limits</title>
<updated>2023-02-22T11:50:27+00:00</updated>
<author>
<name>Samuel Thibault</name>
<email>samuel.thibault@ens-lyon.org</email>
</author>
<published>2023-01-29T15:17:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4abcd352a0222cc807f6f87d2f58d59aeeb70340'/>
<id>4abcd352a0222cc807f6f87d2f58d59aeeb70340</id>
<content type='text'>
commit 2b09d5d364986f724f17001ccfe4126b9b43a0be upstream.

blit_x and blit_y are u32, so fbcon currently cannot support fonts
larger than 32x32.

The 32x32 case also needs shifting an unsigned int, to properly set bit
31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
as reported on:

http://lore.kernel.org/all/IA1PR07MB98308653E259A6F2CE94A4AFABCE9@IA1PR07MB9830.namprd07.prod.outlook.com
Kernel Branch: 6.2.0-rc5-next-20230124
Kernel config: https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
Reproducer: https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing

Reported-by: Sanan Hasanov &lt;sanan.hasanov@Knights.ucf.edu&gt;
Signed-off-by: Samuel Thibault &lt;samuel.thibault@ens-lyon.org&gt;
Fixes: 2d2699d98492 ("fbcon: font setting should check limitation of driver")
Cc: stable@vger.kernel.org
Tested-by: Miko Larsson &lt;mikoxyzzz@gmail.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2b09d5d364986f724f17001ccfe4126b9b43a0be upstream.

blit_x and blit_y are u32, so fbcon currently cannot support fonts
larger than 32x32.

The 32x32 case also needs shifting an unsigned int, to properly set bit
31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
as reported on:

http://lore.kernel.org/all/IA1PR07MB98308653E259A6F2CE94A4AFABCE9@IA1PR07MB9830.namprd07.prod.outlook.com
Kernel Branch: 6.2.0-rc5-next-20230124
Kernel config: https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
Reproducer: https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing

Reported-by: Sanan Hasanov &lt;sanan.hasanov@Knights.ucf.edu&gt;
Signed-off-by: Samuel Thibault &lt;samuel.thibault@ens-lyon.org&gt;
Fixes: 2d2699d98492 ("fbcon: font setting should check limitation of driver")
Cc: stable@vger.kernel.org
Tested-by: Miko Larsson &lt;mikoxyzzz@gmail.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: uvesafb: Fixes an error handling path in uvesafb_probe()</title>
<updated>2023-01-18T10:41:27+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2022-12-10T11:35:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0f049375ad495cc0649a1242663e4cb32d1e0b7b'/>
<id>0f049375ad495cc0649a1242663e4cb32d1e0b7b</id>
<content type='text'>
[ Upstream commit a94371040712031ba129c7e9d8ff04a06a2f8207 ]

If an error occurs after a successful uvesafb_init_mtrr() call, it must be
undone by a corresponding arch_phys_wc_del() call, as already done in the
remove function.

This has been added in the remove function in commit 63e28a7a5ffc
("uvesafb: Clean up MTRR code")

Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a94371040712031ba129c7e9d8ff04a06a2f8207 ]

If an error occurs after a successful uvesafb_init_mtrr() call, it must be
undone by a corresponding arch_phys_wc_del() call, as already done in the
remove function.

This has been added in the remove function in commit 63e28a7a5ffc
("uvesafb: Clean up MTRR code")

Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
