<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/video/console, branch linux-3.16.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>vgacon: Fix a UAF in vgacon_invert_region</title>
<updated>2020-04-28T18:03:40+00:00</updated>
<author>
<name>Zhang Xiaoxu</name>
<email>zhangxiaoxu5@huawei.com</email>
</author>
<published>2020-03-04T02:24:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bca2e2e83484ff63ca82c9c2c905d4e580f1a35a'/>
<id>bca2e2e83484ff63ca82c9c2c905d4e580f1a35a</id>
<content type='text'>
commit 513dc792d6060d5ef572e43852683097a8420f56 upstream.

When syzkaller tests, there is a UAF:
  BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
    ffff880000100000
  Read of size 2 by task syz-executor.1/16489
  page:ffffea0000004000 count:0 mapcount:-127 mapping:          (null)
  index:0x0
  page flags: 0xfffff00000000()
  page dumped because: kasan: bad access detected
  CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
  rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
  Call Trace:
    [&lt;ffffffffb119f309&gt;] dump_stack+0x1e/0x20
    [&lt;ffffffffb04af957&gt;] kasan_report+0x577/0x950
    [&lt;ffffffffb04ae652&gt;] __asan_load2+0x62/0x80
    [&lt;ffffffffb090f26d&gt;] vgacon_invert_region+0x9d/0x110
    [&lt;ffffffffb0a39d95&gt;] invert_screen+0xe5/0x470
    [&lt;ffffffffb0a21dcb&gt;] set_selection+0x44b/0x12f0
    [&lt;ffffffffb0a3bfae&gt;] tioclinux+0xee/0x490
    [&lt;ffffffffb0a1d114&gt;] vt_ioctl+0xff4/0x2670
    [&lt;ffffffffb0a0089a&gt;] tty_ioctl+0x46a/0x1a10
    [&lt;ffffffffb052db3d&gt;] do_vfs_ioctl+0x5bd/0xc40
    [&lt;ffffffffb052e2f2&gt;] SyS_ioctl+0x132/0x170
    [&lt;ffffffffb11c9b1b&gt;] system_call_fastpath+0x22/0x27
    Memory state around the buggy address:
     ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00
     ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00
    &gt;ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff

It can be reproduce in the linux mainline by the program:
  #include &lt;stdio.h&gt;
  #include &lt;stdlib.h&gt;
  #include &lt;unistd.h&gt;
  #include &lt;fcntl.h&gt;
  #include &lt;sys/types.h&gt;
  #include &lt;sys/stat.h&gt;
  #include &lt;sys/ioctl.h&gt;
  #include &lt;linux/vt.h&gt;

  struct tiocl_selection {
    unsigned short xs;      /* X start */
    unsigned short ys;      /* Y start */
    unsigned short xe;      /* X end */
    unsigned short ye;      /* Y end */
    unsigned short sel_mode; /* selection mode */
  };

  #define TIOCL_SETSEL    2
  struct tiocl {
    unsigned char type;
    unsigned char pad;
    struct tiocl_selection sel;
  };

  int main()
  {
    int fd = 0;
    const char *dev = "/dev/char/4:1";

    struct vt_consize v = {0};
    struct tiocl tioc = {0};

    fd = open(dev, O_RDWR, 0);

    v.v_rows = 3346;
    ioctl(fd, VT_RESIZEX, &amp;v);

    tioc.type = TIOCL_SETSEL;
    ioctl(fd, TIOCLINUX, &amp;tioc);

    return 0;
  }

When resize the screen, update the 'vc-&gt;vc_size_row' to the new_row_size,
but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base'
for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe
smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc
the offset, it maybe larger than the vga_vram_size in vgacon driver, then
bad access.
Also, if set an larger screenbuf firstly, then set an more larger
screenbuf, when copy old_origin to new_origin, a bad access may happen.

So, If the screen size larger than vga_vram, resize screen should be
failed. This alse fix CVE-2020-8649 and CVE-2020-8647.

Linus pointed out that overflow checking seems absent. We're saved by
the existing bounds checks in vc_do_resize() with rather strict
limits:

	if (cols &gt; VC_RESIZE_MAXCOL || lines &gt; VC_RESIZE_MAXROW)
		return -EINVAL;

Fixes: 0aec4867dca14 ("[PATCH] SVGATextMode fix")
Reference: CVE-2020-8647 and CVE-2020-8649
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Zhang Xiaoxu &lt;zhangxiaoxu5@huawei.com&gt;
[danvet: augment commit message to point out overflow safety]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 513dc792d6060d5ef572e43852683097a8420f56 upstream.

When syzkaller tests, there is a UAF:
  BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
    ffff880000100000
  Read of size 2 by task syz-executor.1/16489
  page:ffffea0000004000 count:0 mapcount:-127 mapping:          (null)
  index:0x0
  page flags: 0xfffff00000000()
  page dumped because: kasan: bad access detected
  CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
  rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
  Call Trace:
    [&lt;ffffffffb119f309&gt;] dump_stack+0x1e/0x20
    [&lt;ffffffffb04af957&gt;] kasan_report+0x577/0x950
    [&lt;ffffffffb04ae652&gt;] __asan_load2+0x62/0x80
    [&lt;ffffffffb090f26d&gt;] vgacon_invert_region+0x9d/0x110
    [&lt;ffffffffb0a39d95&gt;] invert_screen+0xe5/0x470
    [&lt;ffffffffb0a21dcb&gt;] set_selection+0x44b/0x12f0
    [&lt;ffffffffb0a3bfae&gt;] tioclinux+0xee/0x490
    [&lt;ffffffffb0a1d114&gt;] vt_ioctl+0xff4/0x2670
    [&lt;ffffffffb0a0089a&gt;] tty_ioctl+0x46a/0x1a10
    [&lt;ffffffffb052db3d&gt;] do_vfs_ioctl+0x5bd/0xc40
    [&lt;ffffffffb052e2f2&gt;] SyS_ioctl+0x132/0x170
    [&lt;ffffffffb11c9b1b&gt;] system_call_fastpath+0x22/0x27
    Memory state around the buggy address:
     ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00
     ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00
    &gt;ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff

It can be reproduce in the linux mainline by the program:
  #include &lt;stdio.h&gt;
  #include &lt;stdlib.h&gt;
  #include &lt;unistd.h&gt;
  #include &lt;fcntl.h&gt;
  #include &lt;sys/types.h&gt;
  #include &lt;sys/stat.h&gt;
  #include &lt;sys/ioctl.h&gt;
  #include &lt;linux/vt.h&gt;

  struct tiocl_selection {
    unsigned short xs;      /* X start */
    unsigned short ys;      /* Y start */
    unsigned short xe;      /* X end */
    unsigned short ye;      /* Y end */
    unsigned short sel_mode; /* selection mode */
  };

  #define TIOCL_SETSEL    2
  struct tiocl {
    unsigned char type;
    unsigned char pad;
    struct tiocl_selection sel;
  };

  int main()
  {
    int fd = 0;
    const char *dev = "/dev/char/4:1";

    struct vt_consize v = {0};
    struct tiocl tioc = {0};

    fd = open(dev, O_RDWR, 0);

    v.v_rows = 3346;
    ioctl(fd, VT_RESIZEX, &amp;v);

    tioc.type = TIOCL_SETSEL;
    ioctl(fd, TIOCLINUX, &amp;tioc);

    return 0;
  }

When resize the screen, update the 'vc-&gt;vc_size_row' to the new_row_size,
but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base'
for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe
smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc
the offset, it maybe larger than the vga_vram_size in vgacon driver, then
bad access.
Also, if set an larger screenbuf firstly, then set an more larger
screenbuf, when copy old_origin to new_origin, a bad access may happen.

So, If the screen size larger than vga_vram, resize screen should be
failed. This alse fix CVE-2020-8649 and CVE-2020-8647.

Linus pointed out that overflow checking seems absent. We're saved by
the existing bounds checks in vc_do_resize() with rather strict
limits:

	if (cols &gt; VC_RESIZE_MAXCOL || lines &gt; VC_RESIZE_MAXROW)
		return -EINVAL;

Fixes: 0aec4867dca14 ("[PATCH] SVGATextMode fix")
Reference: CVE-2020-8647 and CVE-2020-8649
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Zhang Xiaoxu &lt;zhangxiaoxu5@huawei.com&gt;
[danvet: augment commit message to point out overflow safety]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbdev: fbcon: Fix unregister crash when more than one framebuffer</title>
<updated>2019-04-04T15:14:02+00:00</updated>
<author>
<name>Noralf Trønnes</name>
<email>noralf@tronnes.org</email>
</author>
<published>2018-12-20T18:13:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=763ae3d61a9b1a22b856e1340b4eb35597cebe17'/>
<id>763ae3d61a9b1a22b856e1340b4eb35597cebe17</id>
<content type='text'>
commit 2122b40580dd9d0620398739c773d07a7b7939d0 upstream.

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 __queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [&lt;c010d388&gt;] (dump_backtrace) from [&lt;c010d670&gt;] (show_stack+0x20/0x24)
[   76.479022]  r6:00000000 r5:c0bc73be r4:00000000 r3:6fb5bf81
[   76.479060] [&lt;c010d650&gt;] (show_stack) from [&lt;c08e82f4&gt;] (dump_stack+0x20/0x28)
[   76.479102] [&lt;c08e82d4&gt;] (dump_stack) from [&lt;c0120070&gt;] (__warn+0xec/0x12c)
[   76.479134] [&lt;c011ff84&gt;] (__warn) from [&lt;c01201e4&gt;] (warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:00000001 r7:c0e927f8 r6:c0bc73be r5:000005a2 r4:c0139e84
[   76.479197] [&lt;c0120198&gt;] (warn_slowpath_null) from [&lt;c0139e84&gt;] (__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [&lt;c0139bb0&gt;] (__queue_work) from [&lt;c013a02c&gt;] (queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:00000100 r8:c0e92ae0 r7:00000001 r6:d9403700 r5:d7666a00
[   76.479298]  r4:20000113
[   76.479348] [&lt;c0139fcc&gt;] (queue_work_on) from [&lt;c0496c28&gt;] (cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [&lt;c0496bf8&gt;] (cursor_timer_handler) from [&lt;c0178744&gt;] (call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [&lt;c0178644&gt;] (call_timer_fn) from [&lt;c0178980&gt;] (expire_timers+0x10c/0x12c)
[   76.479495]  r10:40000000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [&lt;c0178874&gt;] (expire_timers) from [&lt;c0179630&gt;] (run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:00000001 r8:c0e19280 r7:00000000 r6:c0e08088 r5:c0e1a3e0 r4:c0e19280
[   76.479603] [&lt;c0179588&gt;] (run_timer_softirq) from [&lt;c0102404&gt;] (__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:0000000a r7:00000100 r6:00000001 r5:00000002
[   76.479650]  r4:c0eb65ec
[   76.479686] [&lt;c0102258&gt;] (__do_softirq) from [&lt;c0124d10&gt;] (irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:00000001 r7:d949c000 r6:00000000 r5:c0e8b3f0
[   76.479734]  r4:00000000
[   76.479764] [&lt;c0124c28&gt;] (irq_exit) from [&lt;c016b72c&gt;] (__handle_domain_irq+0x94/0xb0)
[   76.479793] [&lt;c016b698&gt;] (__handle_domain_irq) from [&lt;c01021dc&gt;] (bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6:ffffffff r5:c0e089f8 r4:d8afddc8 r3:d8afddc8
[   76.479851] [&lt;c01021a0&gt;] (bcm2835_handle_irq) from [&lt;c01019f0&gt;] (__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from unregister_framebuffer")
Signed-off-by: Noralf Trønnes &lt;noralf@tronnes.org&gt;
Reviewed-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2122b40580dd9d0620398739c773d07a7b7939d0 upstream.

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 __queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [&lt;c010d388&gt;] (dump_backtrace) from [&lt;c010d670&gt;] (show_stack+0x20/0x24)
[   76.479022]  r6:00000000 r5:c0bc73be r4:00000000 r3:6fb5bf81
[   76.479060] [&lt;c010d650&gt;] (show_stack) from [&lt;c08e82f4&gt;] (dump_stack+0x20/0x28)
[   76.479102] [&lt;c08e82d4&gt;] (dump_stack) from [&lt;c0120070&gt;] (__warn+0xec/0x12c)
[   76.479134] [&lt;c011ff84&gt;] (__warn) from [&lt;c01201e4&gt;] (warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:00000001 r7:c0e927f8 r6:c0bc73be r5:000005a2 r4:c0139e84
[   76.479197] [&lt;c0120198&gt;] (warn_slowpath_null) from [&lt;c0139e84&gt;] (__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [&lt;c0139bb0&gt;] (__queue_work) from [&lt;c013a02c&gt;] (queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:00000100 r8:c0e92ae0 r7:00000001 r6:d9403700 r5:d7666a00
[   76.479298]  r4:20000113
[   76.479348] [&lt;c0139fcc&gt;] (queue_work_on) from [&lt;c0496c28&gt;] (cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [&lt;c0496bf8&gt;] (cursor_timer_handler) from [&lt;c0178744&gt;] (call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [&lt;c0178644&gt;] (call_timer_fn) from [&lt;c0178980&gt;] (expire_timers+0x10c/0x12c)
[   76.479495]  r10:40000000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [&lt;c0178874&gt;] (expire_timers) from [&lt;c0179630&gt;] (run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:00000001 r8:c0e19280 r7:00000000 r6:c0e08088 r5:c0e1a3e0 r4:c0e19280
[   76.479603] [&lt;c0179588&gt;] (run_timer_softirq) from [&lt;c0102404&gt;] (__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:0000000a r7:00000100 r6:00000001 r5:00000002
[   76.479650]  r4:c0eb65ec
[   76.479686] [&lt;c0102258&gt;] (__do_softirq) from [&lt;c0124d10&gt;] (irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:00000001 r7:d949c000 r6:00000000 r5:c0e8b3f0
[   76.479734]  r4:00000000
[   76.479764] [&lt;c0124c28&gt;] (irq_exit) from [&lt;c016b72c&gt;] (__handle_domain_irq+0x94/0xb0)
[   76.479793] [&lt;c016b698&gt;] (__handle_domain_irq) from [&lt;c01021dc&gt;] (bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6:ffffffff r5:c0e089f8 r4:d8afddc8 r3:d8afddc8
[   76.479851] [&lt;c01021a0&gt;] (bcm2835_handle_irq) from [&lt;c01019f0&gt;] (__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from unregister_framebuffer")
Signed-off-by: Noralf Trønnes &lt;noralf@tronnes.org&gt;
Reviewed-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>console/dummy: leave .con_font_get set to NULL</title>
<updated>2018-06-16T21:21:53+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nicolas.pitre@linaro.org</email>
</author>
<published>2018-01-15T16:04:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=92e516eb79788458bc1e2feebcc9c7998112e443'/>
<id>92e516eb79788458bc1e2feebcc9c7998112e443</id>
<content type='text'>
commit 724ba8b30b044aa0d94b1cd374fc15806cdd6f18 upstream.

When this method is set, the caller expects struct console_font fields
to be properly initialized when it returns. Leave it unset otherwise
nonsensical (leaked kernel stack) values are returned to user space.

Signed-off-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 724ba8b30b044aa0d94b1cd374fc15806cdd6f18 upstream.

When this method is set, the caller expects struct console_font fields
to be properly initialized when it returns. Leave it unset otherwise
nonsensical (leaked kernel stack) values are returned to user space.

Signed-off-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>framebuffer: fix border color</title>
<updated>2014-11-17T14:11:46+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2014-09-16T16:40:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4187f126d40a3a1a976d366ed07ff0f5f1128c50'/>
<id>4187f126d40a3a1a976d366ed07ff0f5f1128c50</id>
<content type='text'>
commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream.

The framebuffer code uses the current background color to fill the border
when switching consoles, however, this results in inconsistent behavior.
For example:
- start Midnigh Commander
- the border is black
- switch to another console and switch back
- the border is cyan
- type something into the command line in mc
- the border is cyan
- switch to another console and switch back
- the border is black
- press F9 to go to menu
- the border is black
- switch to another console and switch back
- the border is dark blue

When switching to a console with Midnight Commander, the border is random
color that was left selected by the slang subsystem.

This patch fixes this inconsistency by always using black as the
background color when switching consoles.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream.

The framebuffer code uses the current background color to fill the border
when switching consoles, however, this results in inconsistent behavior.
For example:
- start Midnigh Commander
- the border is black
- switch to another console and switch back
- the border is cyan
- type something into the command line in mc
- the border is cyan
- switch to another console and switch back
- the border is black
- press F9 to go to menu
- the border is black
- switch to another console and switch back
- the border is dark blue

When switching to a console with Midnight Commander, the border is random
color that was left selected by the slang subsystem.

This patch fixes this inconsistency by always using black as the
background color when switching consoles.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'drm-intel-fixes-2014-06-17' of git://anongit.freedesktop.org/drm-intel into drm-next</title>
<updated>2014-06-19T00:54:35+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2014-06-19T00:54:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=884d6147ba19640a40fb45efe64360cdf92cac27'/>
<id>884d6147ba19640a40fb45efe64360cdf92cac27</id>
<content type='text'>
First round of fixes for 3.16-rc, mostly cc: stable, and the vt/vgacon
fixes from Daniel [1] to avoid hangs and unclaimed register errors on
module load/reload.

* tag 'drm-intel-fixes-2014-06-17' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/bdw: remove erroneous chv specific workarounds from bdw code
  drm/i915: fix possible refcount leak when resetting forcewake
  drm/i915: Reorder semaphore deadlock check
  drm/i95: Initialize active ring-&gt;pid to -1
  drm/i915: set backlight duty cycle after backlight enable for gen4
  drm/i915: Avoid div-by-zero when pixel_multiplier is zero
  drm/i915: Disable FBC by default also on Haswell and later
  drm/i915: Kick out vga console
  drm/i915: Fixup global gtt cleanup
  vt: Don't ignore unbind errors in vt_unbind
  vt: Fix up unregistration of vt drivers
  vt: Fix replacement console check when unbinding
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
First round of fixes for 3.16-rc, mostly cc: stable, and the vt/vgacon
fixes from Daniel [1] to avoid hangs and unclaimed register errors on
module load/reload.

* tag 'drm-intel-fixes-2014-06-17' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/bdw: remove erroneous chv specific workarounds from bdw code
  drm/i915: fix possible refcount leak when resetting forcewake
  drm/i915: Reorder semaphore deadlock check
  drm/i95: Initialize active ring-&gt;pid to -1
  drm/i915: set backlight duty cycle after backlight enable for gen4
  drm/i915: Avoid div-by-zero when pixel_multiplier is zero
  drm/i915: Disable FBC by default also on Haswell and later
  drm/i915: Kick out vga console
  drm/i915: Fixup global gtt cleanup
  vt: Don't ignore unbind errors in vt_unbind
  vt: Fix up unregistration of vt drivers
  vt: Fix replacement console check when unbinding
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: Kick out vga console</title>
<updated>2014-06-09T19:03:47+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2014-06-05T14:20:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a4de05268e674e8ed31df6348269e22d6c6a1803'/>
<id>a4de05268e674e8ed31df6348269e22d6c6a1803</id>
<content type='text'>
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.

Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.

Also, we want this to make I915_FBDEV=n safe.

v2: Rebase and pimp commit message.

v3: We also need to unregister the vga console, otherwise the unbind
of the fb console before module unload might resurrect it again.

v4: Ignore errors when the vga console is already unregistered - this
can happen when e.g. reloading i915.ko.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Cc: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Cc: Jean-Christophe Plagniol-Villard &lt;plagnioj@jcrosoft.com&gt;
Cc: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: linux-fbdev@vger.kernel.org
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt; (v1)
Reviewed-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Acked-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.

Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.

Also, we want this to make I915_FBDEV=n safe.

v2: Rebase and pimp commit message.

v3: We also need to unregister the vga console, otherwise the unbind
of the fb console before module unload might resurrect it again.

v4: Ignore errors when the vga console is already unregistered - this
can happen when e.g. reloading i915.ko.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Cc: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Cc: Jean-Christophe Plagniol-Villard &lt;plagnioj@jcrosoft.com&gt;
Cc: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: linux-fbdev@vger.kernel.org
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt; (v1)
Reviewed-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Acked-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'fbdev-main-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into next</title>
<updated>2014-06-04T16:05:12+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-06-04T16:05:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d55696af8d91e8f21dacd74a236e6dcc4f6d78c4'/>
<id>d55696af8d91e8f21dacd74a236e6dcc4f6d78c4</id>
<content type='text'>
Pull main fbdev changes from Tomi Valkeinen:
 "Mainly fixes and small improvements.  The biggest change seems to be
  backlight control support for mx3fb"

* tag 'fbdev-main-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (31 commits)
  drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap
  video: fbdev: s3fb.c: Fix for possible null pointer dereference
  video: fbdev: grvga.c: Fix for possible null pointer dereference
  matroxfb: perform a dummy read of M_STATUS
  video: of: display_timing: fix default native-mode setting
  video: delete unneeded call to platform_get_drvdata
  video: mx3fb: Add backlight control support
  video: omap: delete support for early fbmem allocation
  video: of: display_timing: remove two unsafe error messages
  fbdev: fbmem: remove positive test on unsigned values
  fbcon: Fix memory leak in con2fb_release_oldinfo()
  video: Kconfig: Add a dependency to the Goldfish framebuffer driver
  video: exynos: Add a dependency to the menu
  video: mx3fb: Use devm_kzalloc
  video/nuc900: allow modular build
  video: atmel needs FB_BACKLIGHT
  video: export fb_prepare_logo
  video/mbx: fix building debugfs support
  video/omap: fix modular build
  video: clarify I2C dependencies
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull main fbdev changes from Tomi Valkeinen:
 "Mainly fixes and small improvements.  The biggest change seems to be
  backlight control support for mx3fb"

* tag 'fbdev-main-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (31 commits)
  drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap
  video: fbdev: s3fb.c: Fix for possible null pointer dereference
  video: fbdev: grvga.c: Fix for possible null pointer dereference
  matroxfb: perform a dummy read of M_STATUS
  video: of: display_timing: fix default native-mode setting
  video: delete unneeded call to platform_get_drvdata
  video: mx3fb: Add backlight control support
  video: omap: delete support for early fbmem allocation
  video: of: display_timing: remove two unsafe error messages
  fbdev: fbmem: remove positive test on unsigned values
  fbcon: Fix memory leak in con2fb_release_oldinfo()
  video: Kconfig: Add a dependency to the Goldfish framebuffer driver
  video: exynos: Add a dependency to the menu
  video: mx3fb: Use devm_kzalloc
  video/nuc900: allow modular build
  video: atmel needs FB_BACKLIGHT
  video: export fb_prepare_logo
  video/mbx: fix building debugfs support
  video/omap: fix modular build
  video: clarify I2C dependencies
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>console: Use explicit pointer type for vc_uni_pagedir* fields</title>
<updated>2014-05-28T20:37:21+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2014-05-13T10:09:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e4bdab70dd07d8648a1ec3e029239aa86eb836b6'/>
<id>e4bdab70dd07d8648a1ec3e029239aa86eb836b6</id>
<content type='text'>
The vc_data.vc_uni_pagedir filed is currently long int, supposedly to
be served generically.  This, however, leads to lots of cast to
pointer, and rather it worsens the readability significantly.

Actually, we have now only a single uni_pagedir map implementation,
and this won't change likely.  So, it'd be much more simple and
error-prone to just use the exact pointer for struct uni_pagedir
instead of long.

Ditto for vc_uni_pagedir_loc.  It's a pointer to the uni_pagedir, thus
it can be changed similarly to the exact type.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.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>
The vc_data.vc_uni_pagedir filed is currently long int, supposedly to
be served generically.  This, however, leads to lots of cast to
pointer, and rather it worsens the readability significantly.

Actually, we have now only a single uni_pagedir map implementation,
and this won't change likely.  So, it'd be much more simple and
error-prone to just use the exact pointer for struct uni_pagedir
instead of long.

Ditto for vc_uni_pagedir_loc.  It's a pointer to the uni_pagedir, thus
it can be changed similarly to the exact type.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vgacon: Fix &amp; cleanup refcounting</title>
<updated>2014-05-28T20:37:21+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2014-05-13T10:09:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0f2893f0d1acff4bb1677b60c0486adc0075cb99'/>
<id>0f2893f0d1acff4bb1677b60c0486adc0075cb99</id>
<content type='text'>
The vgacon driver prepares a two element array of uni_pagedir_loc and
uses the second item as its own reference counter for sharing the
uni_pagedir.  And the code assumes blindly that the second item is
available if the assigned vc_uni_pagedir isn't the standard one, which
might be wrong (although currently it's so).

This patch fixes that wrong assumption, and gives a slight cleanup
along with it: namely, instead of array, just give the uni_pagedir_loc
and a separate refcount variable.  It makes the code a bit more
understandable at first glance.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.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>
The vgacon driver prepares a two element array of uni_pagedir_loc and
uses the second item as its own reference counter for sharing the
uni_pagedir.  And the code assumes blindly that the second item is
available if the assigned vc_uni_pagedir isn't the standard one, which
might be wrong (although currently it's so).

This patch fixes that wrong assumption, and gives a slight cleanup
along with it: namely, instead of array, just give the uni_pagedir_loc
and a separate refcount variable.  It makes the code a bit more
understandable at first glance.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fbcon: Fix memory leak in con2fb_release_oldinfo()</title>
<updated>2014-05-09T09:55:49+00:00</updated>
<author>
<name>Masami Ichikawa</name>
<email>masami256@gmail.com</email>
</author>
<published>2014-04-23T14:35:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7a966fbd78683fe4ff7f019fd80fc08d9753880b'/>
<id>7a966fbd78683fe4ff7f019fd80fc08d9753880b</id>
<content type='text'>
kmemleak reported a memory leak as below.

unreferenced object 0xffff8800dab6d8d8 (size 96):
  comm "swapper/0", pid 1, jiffies 4294877598 (age 38.483s)
  hex dump (first 32 bytes):
    00 00 00 00 00 01 00 00 08 00 00 00 10 00 00 00  ................
    07 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff814e8f2e&gt;] kmemleak_alloc+0x4e/0xb0
    [&lt;ffffffff811a0600&gt;] __kmalloc+0x280/0x320
    [&lt;ffffffff81309b61&gt;] soft_cursor+0x231/0x290
    [&lt;ffffffff81309393&gt;] bit_cursor+0x613/0x650
    [&lt;ffffffff8130556b&gt;] fbcon_cursor+0x13b/0x1c0
    [&lt;ffffffff813755f8&gt;] hide_cursor+0x28/0xa0
    [&lt;ffffffff81376e98&gt;] redraw_screen+0x168/0x240
    [&lt;ffffffff81303891&gt;] fbcon_prepare_logo+0x381/0x420
    [&lt;ffffffff81303c7e&gt;] fbcon_init+0x34e/0x590
    [&lt;ffffffff81375828&gt;] visual_init+0xb8/0x120
    [&lt;ffffffff81377c93&gt;] do_bind_con_driver+0x163/0x380
    [&lt;ffffffff81378494&gt;] do_take_over_console+0x114/0x1c0
    [&lt;ffffffff81303f23&gt;] do_fbcon_takeover+0x63/0xd0
    [&lt;ffffffff813086dd&gt;] fbcon_event_notify+0x68d/0x7e0
    [&lt;ffffffff814ff7ac&gt;] notifier_call_chain+0x4c/0x70
    [&lt;ffffffff8108c85d&gt;] __blocking_notifier_call_chain+0x4d/0x70

This memory leak cause is, fbcon_ops's cursor_src is allocated in
soft_cursor() but not released in con2fb_release_oldinfo().
so, cursor_src is needed to be released when oldinfo is going to be
released.

Signed-off-by: Masami Ichikawa &lt;masami256@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kmemleak reported a memory leak as below.

unreferenced object 0xffff8800dab6d8d8 (size 96):
  comm "swapper/0", pid 1, jiffies 4294877598 (age 38.483s)
  hex dump (first 32 bytes):
    00 00 00 00 00 01 00 00 08 00 00 00 10 00 00 00  ................
    07 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff814e8f2e&gt;] kmemleak_alloc+0x4e/0xb0
    [&lt;ffffffff811a0600&gt;] __kmalloc+0x280/0x320
    [&lt;ffffffff81309b61&gt;] soft_cursor+0x231/0x290
    [&lt;ffffffff81309393&gt;] bit_cursor+0x613/0x650
    [&lt;ffffffff8130556b&gt;] fbcon_cursor+0x13b/0x1c0
    [&lt;ffffffff813755f8&gt;] hide_cursor+0x28/0xa0
    [&lt;ffffffff81376e98&gt;] redraw_screen+0x168/0x240
    [&lt;ffffffff81303891&gt;] fbcon_prepare_logo+0x381/0x420
    [&lt;ffffffff81303c7e&gt;] fbcon_init+0x34e/0x590
    [&lt;ffffffff81375828&gt;] visual_init+0xb8/0x120
    [&lt;ffffffff81377c93&gt;] do_bind_con_driver+0x163/0x380
    [&lt;ffffffff81378494&gt;] do_take_over_console+0x114/0x1c0
    [&lt;ffffffff81303f23&gt;] do_fbcon_takeover+0x63/0xd0
    [&lt;ffffffff813086dd&gt;] fbcon_event_notify+0x68d/0x7e0
    [&lt;ffffffff814ff7ac&gt;] notifier_call_chain+0x4c/0x70
    [&lt;ffffffff8108c85d&gt;] __blocking_notifier_call_chain+0x4d/0x70

This memory leak cause is, fbcon_ops's cursor_src is allocated in
soft_cursor() but not released in con2fb_release_oldinfo().
so, cursor_src is needed to be released when oldinfo is going to be
released.

Signed-off-by: Masami Ichikawa &lt;masami256@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
