<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/drivers/media, branch linux-3.12.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-3.12.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-3.12.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2017-05-03T12:22:42+00:00</updated>
<entry>
<title>dvb-usb-v2: avoid use-after-free</title>
<updated>2017-05-03T12:22:42+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-02-02T14:36:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=03662cd00e03d0fe34f9f91217313a4544b71c60'/>
<id>urn:sha1:03662cd00e03d0fe34f9f91217313a4544b71c60</id>
<content type='text'>
commit 005145378c9ad7575a01b6ce1ba118fb427f583a upstream.

I ran into a stack frame size warning because of the on-stack copy of
the USB device structure:

drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usbv2_disconnect':
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1029:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

Copying a device structure like this is wrong for a number of other reasons
too aside from the possible stack overflow. One of them is that the
dev_info() call will print the name of the device later, but AFAICT
we have only copied a pointer to the name earlier and the actual name
has been freed by the time it gets printed.

This removes the on-stack copy of the device and instead copies the
device name using kstrdup(). I'm ignoring the possible failure here
as both printk() and kfree() are able to deal with NULL pointers.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>uvcvideo: uvc_scan_fallback() for webcams with broken chain</title>
<updated>2017-04-07T08:38:28+00:00</updated>
<author>
<name>Sumit Semwal</name>
<email>sumit.semwal@linaro.org</email>
</author>
<published>2017-03-25T16:18:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=2465421befced558c868b38b228cf9e87e916b6e'/>
<id>urn:sha1:2465421befced558c868b38b228cf9e87e916b6e</id>
<content type='text'>
From: Henrik Ingo &lt;henrik.ingo@avoinelama.fi&gt;

[ Upstream commit e950267ab802c8558f1100eafd4087fd039ad634 ]

Some devices have invalid baSourceID references, causing uvc_scan_chain()
to fail, but if we just take the entities we can find and put them
together in the most sensible chain we can think of, turns out they do
work anyway. Note: This heuristic assumes there is a single chain.

At the time of writing, devices known to have such a broken chain are
  - Acer Integrated Camera (5986:055a)
  - Realtek rtl157a7 (0bda:57a7)

Signed-off-by: Henrik Ingo &lt;henrik.ingo@avoinelama.fi&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>uvcvideo: Fix a wrong macro</title>
<updated>2017-03-13T20:40:20+00:00</updated>
<author>
<name>Guennadi Liakhovetski</name>
<email>g.liakhovetski@gmx.de</email>
</author>
<published>2016-12-12T11:16:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=1cd25ec766d91b6efa426725a9997692433b18a9'/>
<id>urn:sha1:1cd25ec766d91b6efa426725a9997692433b18a9</id>
<content type='text'>
commit 17c341ec0115837a610b2da15e32546e26068234 upstream.

Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes.

Fixes: 6998b6fb4b1c ("[media] uvcvideo: Use videobuf2-vmalloc")

Signed-off-by: Guennadi Liakhovetski &lt;guennadi.liakhovetski@intel.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>siano: make it work again with CONFIG_VMAP_STACK</title>
<updated>2017-03-01T09:38:13+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@s-opensource.com</email>
</author>
<published>2017-02-14T19:47:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=405a5ed0fb6ee2a3584c25f6092cab3ba1ab4da8'/>
<id>urn:sha1:405a5ed0fb6ee2a3584c25f6092cab3ba1ab4da8</id>
<content type='text'>
commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream.

Reported as a Kaffeine bug:
	https://bugs.kde.org/show_bug.cgi?id=375811

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

On Kernel 4.9, the default is to not accept DMA on stack anymore
on x86 architecture. On other architectures, this has been a
requirement since Kernel 2.2. So, after this patch, this driver
should likely work fine on all archs.

Tested with USB ID 2040:5510: Hauppauge Windham

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>s5k4ecgx: select CRC32 helper</title>
<updated>2017-02-15T10:56:08+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-12-09T11:41:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=ba74a41691e417c8c8dedf0b727db7a3a8b34563'/>
<id>urn:sha1:ba74a41691e417c8c8dedf0b727db7a3a8b34563</id>
<content type='text'>
commit c739c0a7c3c2472d7562b8f802cdce44d2597c8b upstream.

A rare randconfig build failure shows up in this driver when
the CRC32 helper is not there:

drivers/media/built-in.o: In function `s5k4ecgx_s_power':
s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le'

This adds the 'select' that all other users of this function have.

Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>xc2028: Fix use-after-free bug properly</title>
<updated>2017-01-27T16:14:57+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-11-17T09:49:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f093600f6a9fd00fa76ad05b8276d4f56c4add78'/>
<id>urn:sha1:f093600f6a9fd00fa76ad05b8276d4f56c4add78</id>
<content type='text'>
commit 22a1e7783e173ab3d86018eb590107d68df46c11 upstream.

The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.

However, it's clearing the wrong pointer; it sets NULL to
priv-&gt;ctrl.fname, but it's anyway overwritten by the next line
memcpy(&amp;priv-&gt;ctrl, p, sizeof(priv-&gt;ctrl)).

OTOH, the actual code accessing the freed string is the strcmp() call
with priv-&gt;fname:
	if (!firmware_name[0] &amp;&amp; p-&gt;fname &amp;&amp;
	    priv-&gt;fname &amp;&amp; strcmp(p-&gt;fname, priv-&gt;fname))
		free_firmware(priv);

where priv-&gt;fname points to the previous file name, and this was
already freed by kfree().

For fixing the bug properly, this patch does the following:

- Keep the copy of firmware file name in only priv-&gt;fname,
  priv-&gt;ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly

Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>[media] xc2028: unlock on error in xc2028_set_config()</title>
<updated>2017-01-27T16:14:56+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2016-02-03T15:34:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=6f9247bccf79bf632384e70eaf04cb65481ead5a'/>
<id>urn:sha1:6f9247bccf79bf632384e70eaf04cb65481ead5a</id>
<content type='text'>
commit 210bd104c6acd31c3c6b8b075b3f12d4a9f6b60d upstream.

We have to unlock before returning -ENOMEM.

Fixes: 8dfbcc4351a0 ('[media] xc2028: avoid use after free')

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>[media] xc2028: avoid use after free</title>
<updated>2017-01-27T16:14:55+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@osg.samsung.com</email>
</author>
<published>2016-01-28T11:22:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=74e3d04ca992bedac5080ed1a817fabf71667210'/>
<id>urn:sha1:74e3d04ca992bedac5080ed1a817fabf71667210</id>
<content type='text'>
commit 8dfbcc4351a0b6d2f2d77f367552f48ffefafe18 upstream.

If struct xc2028_config is passed without a firmware name,
the following trouble may happen:

[11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
[11009.907491] ==================================================================
[11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40
[11009.907992] Read of size 1 by task modprobe/28992
[11009.907994] =============================================================================
[11009.907997] BUG kmalloc-16 (Tainted: G        W      ): kasan: bad access detected
[11009.907999] -----------------------------------------------------------------------------

[11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992
[11009.908012] 	___slab_alloc+0x581/0x5b0
[11009.908014] 	__slab_alloc+0x51/0x90
[11009.908017] 	__kmalloc+0x27b/0x350
[11009.908022] 	xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd]
[11009.908026] 	usb_hcd_submit_urb+0x1e8/0x1c60
[11009.908029] 	usb_submit_urb+0xb0e/0x1200
[11009.908032] 	usb_serial_generic_write_start+0xb6/0x4c0
[11009.908035] 	usb_serial_generic_write+0x92/0xc0
[11009.908039] 	usb_console_write+0x38a/0x560
[11009.908045] 	call_console_drivers.constprop.14+0x1ee/0x2c0
[11009.908051] 	console_unlock+0x40d/0x900
[11009.908056] 	vprintk_emit+0x4b4/0x830
[11009.908061] 	vprintk_default+0x1f/0x30
[11009.908064] 	printk+0x99/0xb5
[11009.908067] 	kasan_report_error+0x10a/0x550
[11009.908070] 	__asan_report_load1_noabort+0x43/0x50
[11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992
[11009.908077] 	__slab_free+0x2ec/0x460
[11009.908080] 	kfree+0x266/0x280
[11009.908083] 	xc2028_set_config+0x90/0x630 [tuner_xc2028]
[11009.908086] 	xc2028_attach+0x310/0x8a0 [tuner_xc2028]
[11009.908090] 	em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
[11009.908094] 	em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
[11009.908098] 	em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
[11009.908101] 	em28xx_register_extension+0xd9/0x190 [em28xx]
[11009.908105] 	em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
[11009.908108] 	do_one_initcall+0x141/0x300
[11009.908111] 	do_init_module+0x1d0/0x5ad
[11009.908114] 	load_module+0x6666/0x9ba0
[11009.908117] 	SyS_finit_module+0x108/0x130
[11009.908120] 	entry_SYSCALL_64_fastpath+0x16/0x76
[11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x          (null) flags=0x2ffff8000004080
[11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001

[11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00  ....*....(......
[11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff  ...........j....
[11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G    B   W       4.5.0-rc1+ #43
[11009.908140] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[11009.908142]  ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80
[11009.908148]  ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280
[11009.908153]  ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4
[11009.908158] Call Trace:
[11009.908162]  [&lt;ffffffff81932007&gt;] dump_stack+0x4b/0x64
[11009.908165]  [&lt;ffffffff81556759&gt;] print_trailer+0xf9/0x150
[11009.908168]  [&lt;ffffffff8155ccb4&gt;] object_err+0x34/0x40
[11009.908171]  [&lt;ffffffff8155f260&gt;] kasan_report_error+0x230/0x550
[11009.908175]  [&lt;ffffffff81237d71&gt;] ? trace_hardirqs_off_caller+0x21/0x290
[11009.908179]  [&lt;ffffffff8155e926&gt;] ? kasan_unpoison_shadow+0x36/0x50
[11009.908182]  [&lt;ffffffff8155f5c3&gt;] __asan_report_load1_noabort+0x43/0x50
[11009.908185]  [&lt;ffffffff8155ea00&gt;] ? __asan_register_globals+0x50/0xa0
[11009.908189]  [&lt;ffffffff8194cea6&gt;] ? strcmp+0x96/0xb0
[11009.908192]  [&lt;ffffffff8194cea6&gt;] strcmp+0x96/0xb0
[11009.908196]  [&lt;ffffffffa13ba4ac&gt;] xc2028_set_config+0x15c/0x630 [tuner_xc2028]
[11009.908200]  [&lt;ffffffffa13bac90&gt;] xc2028_attach+0x310/0x8a0 [tuner_xc2028]
[11009.908203]  [&lt;ffffffff8155ea78&gt;] ? memset+0x28/0x30
[11009.908206]  [&lt;ffffffffa13ba980&gt;] ? xc2028_set_config+0x630/0x630 [tuner_xc2028]
[11009.908211]  [&lt;ffffffffa157a59a&gt;] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
[11009.908215]  [&lt;ffffffffa157aa2a&gt;] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb]
[11009.908219]  [&lt;ffffffffa157a3a1&gt;] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb]
[11009.908222]  [&lt;ffffffffa01795ac&gt;] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x]
[11009.908226]  [&lt;ffffffffa01793e0&gt;] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x]
[11009.908230]  [&lt;ffffffff812e87d0&gt;] ? ref_module.part.15+0x10/0x10
[11009.908233]  [&lt;ffffffff812e56e0&gt;] ? module_assert_mutex_or_preempt+0x80/0x80
[11009.908238]  [&lt;ffffffffa157af92&gt;] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
[11009.908242]  [&lt;ffffffffa157a6ae&gt;] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb]
[11009.908245]  [&lt;ffffffff8195222d&gt;] ? string+0x14d/0x1f0
[11009.908249]  [&lt;ffffffff8195381f&gt;] ? symbol_string+0xff/0x1a0
[11009.908253]  [&lt;ffffffff81953720&gt;] ? uuid_string+0x6f0/0x6f0
[11009.908257]  [&lt;ffffffff811a775e&gt;] ? __kernel_text_address+0x7e/0xa0
[11009.908260]  [&lt;ffffffff8104b02f&gt;] ? print_context_stack+0x7f/0xf0
[11009.908264]  [&lt;ffffffff812e9846&gt;] ? __module_address+0xb6/0x360
[11009.908268]  [&lt;ffffffff8137fdc9&gt;] ? is_ftrace_trampoline+0x99/0xe0
[11009.908271]  [&lt;ffffffff811a775e&gt;] ? __kernel_text_address+0x7e/0xa0
[11009.908275]  [&lt;ffffffff81240a70&gt;] ? debug_check_no_locks_freed+0x290/0x290
[11009.908278]  [&lt;ffffffff8104a24b&gt;] ? dump_trace+0x11b/0x300
[11009.908282]  [&lt;ffffffffa13e8143&gt;] ? em28xx_register_extension+0x23/0x190 [em28xx]
[11009.908285]  [&lt;ffffffff81237d71&gt;] ? trace_hardirqs_off_caller+0x21/0x290
[11009.908289]  [&lt;ffffffff8123ff56&gt;] ? trace_hardirqs_on_caller+0x16/0x590
[11009.908292]  [&lt;ffffffff812404dd&gt;] ? trace_hardirqs_on+0xd/0x10
[11009.908296]  [&lt;ffffffffa13e8143&gt;] ? em28xx_register_extension+0x23/0x190 [em28xx]
[11009.908299]  [&lt;ffffffff822dcbb0&gt;] ? mutex_trylock+0x400/0x400
[11009.908302]  [&lt;ffffffff810021a1&gt;] ? do_one_initcall+0x131/0x300
[11009.908306]  [&lt;ffffffff81296dc7&gt;] ? call_rcu_sched+0x17/0x20
[11009.908309]  [&lt;ffffffff8159e708&gt;] ? put_object+0x48/0x70
[11009.908314]  [&lt;ffffffffa1579f11&gt;] em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
[11009.908317]  [&lt;ffffffffa13e81f9&gt;] em28xx_register_extension+0xd9/0x190 [em28xx]
[11009.908320]  [&lt;ffffffffa0150000&gt;] ? 0xffffffffa0150000
[11009.908324]  [&lt;ffffffffa0150010&gt;] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
[11009.908327]  [&lt;ffffffff810021b1&gt;] do_one_initcall+0x141/0x300
[11009.908330]  [&lt;ffffffff81002070&gt;] ? try_to_run_init_process+0x40/0x40
[11009.908333]  [&lt;ffffffff8123ff56&gt;] ? trace_hardirqs_on_caller+0x16/0x590
[11009.908337]  [&lt;ffffffff8155e926&gt;] ? kasan_unpoison_shadow+0x36/0x50
[11009.908340]  [&lt;ffffffff8155e926&gt;] ? kasan_unpoison_shadow+0x36/0x50
[11009.908343]  [&lt;ffffffff8155e926&gt;] ? kasan_unpoison_shadow+0x36/0x50
[11009.908346]  [&lt;ffffffff8155ea37&gt;] ? __asan_register_globals+0x87/0xa0
[11009.908350]  [&lt;ffffffff8144da7b&gt;] do_init_module+0x1d0/0x5ad
[11009.908353]  [&lt;ffffffff812f2626&gt;] load_module+0x6666/0x9ba0
[11009.908356]  [&lt;ffffffff812e9c90&gt;] ? symbol_put_addr+0x50/0x50
[11009.908361]  [&lt;ffffffffa1580037&gt;] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb]
[11009.908366]  [&lt;ffffffff812ebfc0&gt;] ? module_frob_arch_sections+0x20/0x20
[11009.908369]  [&lt;ffffffff815bc940&gt;] ? open_exec+0x50/0x50
[11009.908374]  [&lt;ffffffff811671bb&gt;] ? ns_capable+0x5b/0xd0
[11009.908377]  [&lt;ffffffff812f5e58&gt;] SyS_finit_module+0x108/0x130
[11009.908379]  [&lt;ffffffff812f5d50&gt;] ? SyS_init_module+0x1f0/0x1f0
[11009.908383]  [&lt;ffffffff81004044&gt;] ? lockdep_sys_exit_thunk+0x12/0x14
[11009.908394]  [&lt;ffffffff822e6936&gt;] entry_SYSCALL_64_fastpath+0x16/0x76
[11009.908396] Memory state around the buggy address:
[11009.908398]  ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908401]  ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908403] &gt;ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc
[11009.908405]                                            ^
[11009.908407]  ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908409]  ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[11009.908411] ==================================================================

In order to avoid it, let's set the cached value of the firmware
name to NULL after freeing it. While here, return an error if
the memory allocation fails.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>ite-cir: initialize use_demodulator before using it</title>
<updated>2017-01-27T10:15:58+00:00</updated>
<author>
<name>Nicolas Iooss</name>
<email>nicolas.iooss_linux@m4x.org</email>
</author>
<published>2016-09-10T16:59:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=1c4d4c690779ca67b2b8f654a5183fae69eca8d2'/>
<id>urn:sha1:1c4d4c690779ca67b2b8f654a5183fae69eca8d2</id>
<content type='text'>
commit 7ec03e60ef81c19b5d3a46dd070ee966774b860f upstream.

Function ite_set_carrier_params() uses variable use_demodulator after
having initialized it to false in some if branches, but this variable is
never set to true otherwise.

This bug has been found using clang -Wsometimes-uninitialized warning
flag.

Fixes: 620a32bba4a2 ("[media] rc: New rc-based ite-cir driver for
several ITE CIRs")

Signed-off-by: Nicolas Iooss &lt;nicolas.iooss_linux@m4x.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>dib0700: fix nec repeat handling</title>
<updated>2016-11-24T15:23:41+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2016-11-10T16:44:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=462a6dac43f454a1baf4b381893ff7db2741beb8'/>
<id>urn:sha1:462a6dac43f454a1baf4b381893ff7db2741beb8</id>
<content type='text'>
commit ba13e98f2cebd55a3744c5ffaa08f9dca73bf521 upstream.

When receiving a nec repeat, ensure the correct scancode is repeated
rather than a random value from the stack.  This removes the need for
the bogus uninitialized_var() and also fixes the warnings:

    drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’:
    drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function

[sean addon: So after writing the patch and submitting it, I've bought the
             hardware on ebay. Without this patch you get random scancodes
             on nec repeats, which the patch indeed fixes.]

Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Tested-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
</feed>
