<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers, branch v3.16.48</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>xen: fix bio vec merging</title>
<updated>2017-09-15T17:30:18+00:00</updated>
<author>
<name>Roger Pau Monne</name>
<email>roger.pau@citrix.com</email>
</author>
<published>2017-07-18T14:01:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f664b0113d2bb8d4bcdf5d03b72eb4c433ded452'/>
<id>f664b0113d2bb8d4bcdf5d03b72eb4c433ded452</id>
<content type='text'>
commit 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.

The current test for bio vec merging is not fully accurate and can be
tricked into merging bios when certain grant combinations are used.
The result of these malicious bio merges is a bio that extends past
the memory page used by any of the originating bios.

Take into account the following scenario, where a guest creates two
grant references that point to the same mfn, ie: grant 1 -&gt; mfn A,
grant 2 -&gt; mfn A.

These references are then used in a PV block request, and mapped by
the backend domain, thus obtaining two different pfns that point to
the same mfn, pfn B -&gt; mfn A, pfn C -&gt; mfn A.

If those grants happen to be used in two consecutive sectors of a disk
IO operation becoming two different bios in the backend domain, the
checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
(they both point to the same mfn). However due to the bio merging,
the backend domain will end up with a bio that expands past mfn A into
mfn A + 1.

Fix this by making sure the check in xen_biovec_phys_mergeable takes
into account the offset and the length of the bio, this basically
replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
addresses). While there also remove the usage of
__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
of xen_biovec_phys_mergeable.

Reported-by: "Jan H. Schönherr" &lt;jschoenh@amazon.de&gt;
Signed-off-by: Roger Pau Monné &lt;roger.pau@citrix.com&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.16:
 - s/bfn/mfn/g
 - Adjust context]
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 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.

The current test for bio vec merging is not fully accurate and can be
tricked into merging bios when certain grant combinations are used.
The result of these malicious bio merges is a bio that extends past
the memory page used by any of the originating bios.

Take into account the following scenario, where a guest creates two
grant references that point to the same mfn, ie: grant 1 -&gt; mfn A,
grant 2 -&gt; mfn A.

These references are then used in a PV block request, and mapped by
the backend domain, thus obtaining two different pfns that point to
the same mfn, pfn B -&gt; mfn A, pfn C -&gt; mfn A.

If those grants happen to be used in two consecutive sectors of a disk
IO operation becoming two different bios in the backend domain, the
checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
(they both point to the same mfn). However due to the bio merging,
the backend domain will end up with a bio that expands past mfn A into
mfn A + 1.

Fix this by making sure the check in xen_biovec_phys_mergeable takes
into account the offset and the length of the bio, this basically
replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
addresses). While there also remove the usage of
__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
of xen_biovec_phys_mergeable.

Reported-by: "Jan H. Schönherr" &lt;jschoenh@amazon.de&gt;
Signed-off-by: Roger Pau Monné &lt;roger.pau@citrix.com&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.16:
 - s/bfn/mfn/g
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()</title>
<updated>2017-09-15T17:30:18+00:00</updated>
<author>
<name>Arend van Spriel</name>
<email>arend.vanspriel@broadcom.com</email>
</author>
<published>2017-07-07T20:09:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c63048a29cf222bcd75823b4ca898e2aa6311f8f'/>
<id>c63048a29cf222bcd75823b4ca898e2aa6311f8f</id>
<content type='text'>
commit 8f44c9a41386729fea410e688959ddaa9d51be7c upstream.

The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280.  However, the action_frame-&gt;data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.

	memcpy(action_frame-&gt;data, &amp;buf[DOT11_MGMT_HDR_LEN],
	       le16_to_cpu(action_frame-&gt;len));

Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
Reported-by: "freenerguo(郭大兴)" &lt;freenerguo@tencent.com&gt;
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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 8f44c9a41386729fea410e688959ddaa9d51be7c upstream.

The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280.  However, the action_frame-&gt;data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.

	memcpy(action_frame-&gt;data, &amp;buf[DOT11_MGMT_HDR_LEN],
	       le16_to_cpu(action_frame-&gt;len));

Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
Reported-by: "freenerguo(郭大兴)" &lt;freenerguo@tencent.com&gt;
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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>net: dp83640: Avoid NULL pointer dereference.</title>
<updated>2017-09-15T17:30:15+00:00</updated>
<author>
<name>Richard Cochran</name>
<email>richardcochran@gmail.com</email>
</author>
<published>2017-06-23T15:51:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f4e204d830341635f6570b0cd0933852a742db0f'/>
<id>f4e204d830341635f6570b0cd0933852a742db0f</id>
<content type='text'>
commit db9d8b29d19d2801793e4419f4c6272bf8951c62 upstream.

The function, skb_complete_tx_timestamp(), used to allow passing in a
NULL pointer for the time stamps, but that was changed in commit
62bccb8cdb69051b95a55ab0c489e3cab261c8ef ("net-timestamp: Make the
clone operation stand-alone from phy timestamping"), and the existing
call sites, all of which are in the dp83640 driver, were fixed up.

Even though the kernel-doc was subsequently updated in commit
7a76a021cd5a292be875fbc616daf03eab1e6996 ("net-timestamp: Update
skb_complete_tx_timestamp comment"), still a bug fix from Manfred
Rudigier came into the driver using the old semantics.  Probably
Manfred derived that patch from an older kernel version.

This fix should be applied to the stable trees as well.

Fixes: 81e8f2e930fe ("net: dp83640: Fix tx timestamp overflow handling.")
Signed-off-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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 db9d8b29d19d2801793e4419f4c6272bf8951c62 upstream.

The function, skb_complete_tx_timestamp(), used to allow passing in a
NULL pointer for the time stamps, but that was changed in commit
62bccb8cdb69051b95a55ab0c489e3cab261c8ef ("net-timestamp: Make the
clone operation stand-alone from phy timestamping"), and the existing
call sites, all of which are in the dp83640 driver, were fixed up.

Even though the kernel-doc was subsequently updated in commit
7a76a021cd5a292be875fbc616daf03eab1e6996 ("net-timestamp: Update
skb_complete_tx_timestamp comment"), still a bug fix from Manfred
Rudigier came into the driver using the old semantics.  Probably
Manfred derived that patch from an older kernel version.

This fix should be applied to the stable trees as well.

Fixes: 81e8f2e930fe ("net: dp83640: Fix tx timestamp overflow handling.")
Signed-off-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: imx: Use correct function to write to register</title>
<updated>2017-09-15T17:30:14+00:00</updated>
<author>
<name>Michail Georgios Etairidis</name>
<email>m.etairidis@beck-ipc.com</email>
</author>
<published>2017-06-20T08:20:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1042c14734bce5308ca0f236331e4ed3344a2f11'/>
<id>1042c14734bce5308ca0f236331e4ed3344a2f11</id>
<content type='text'>
commit 6c782a5ea56a799658e213a78dc1455264938afa upstream.

The i2c-imx driver incorrectly uses readb()/writeb() to read and
write to the appropriate registers when performing a repeated start.
The appropriate imx_i2c_read_reg()/imx_i2c_write_reg() functions
should be used instead. Performing a repeated start results in
a kernel panic. The platform is imx.

Signed-off-by: Michail G Etairidis &lt;m.etairidis@beck-ipc.com&gt;
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Fixes: 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart")
Acked-by: Fugang Duan &lt;fugang.duan@nxp.com&gt;
Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
[bwh: Backported to 3.16: drop changes in i2c_imx_dma_read()]
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 6c782a5ea56a799658e213a78dc1455264938afa upstream.

The i2c-imx driver incorrectly uses readb()/writeb() to read and
write to the appropriate registers when performing a repeated start.
The appropriate imx_i2c_read_reg()/imx_i2c_write_reg() functions
should be used instead. Performing a repeated start results in
a kernel panic. The platform is imx.

Signed-off-by: Michail G Etairidis &lt;m.etairidis@beck-ipc.com&gt;
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Fixes: 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart")
Acked-by: Fugang Duan &lt;fugang.duan@nxp.com&gt;
Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
[bwh: Backported to 3.16: drop changes in i2c_imx_dma_read()]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: add a quirk for Toshiba Satellite L20-183</title>
<updated>2017-09-15T17:30:13+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2017-06-19T19:59:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7b0c52983a7439fb6132e072deb5abb4faad90ea'/>
<id>7b0c52983a7439fb6132e072deb5abb4faad90ea</id>
<content type='text'>
commit acfd6ee4fa7ebeee75511825fe02be3f7ac1d668 upstream.

Fixes resume from suspend.

bug: https://bugzilla.kernel.org/show_bug.cgi?id=196121
Reported-by: Przemek &lt;soprwa@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.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 acfd6ee4fa7ebeee75511825fe02be3f7ac1d668 upstream.

Fixes resume from suspend.

bug: https://bugzilla.kernel.org/show_bug.cgi?id=196121
Reported-by: Przemek &lt;soprwa@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: add a PX quirk for another K53TK variant</title>
<updated>2017-09-15T17:30:13+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2017-06-19T16:52:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5f2c2b2434a5e43f7e0a18fdefc6af140b3dd0d5'/>
<id>5f2c2b2434a5e43f7e0a18fdefc6af140b3dd0d5</id>
<content type='text'>
commit 4eb59793cca00b0e629b6d55b5abb5acb82c5868 upstream.

Disable PX on these systems.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=101491
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.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 4eb59793cca00b0e629b6d55b5abb5acb82c5868 upstream.

Disable PX on these systems.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=101491
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list</title>
<updated>2017-09-15T17:30:12+00:00</updated>
<author>
<name>Daniel Drake</name>
<email>drake@endlessm.com</email>
</author>
<published>2017-06-20T02:48:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=017987109b42528436b340675538d8e778c97d20'/>
<id>017987109b42528436b340675538d8e778c97d20</id>
<content type='text'>
commit 817ae460c784f32cd45e60b2b1b21378c3c6a847 upstream.

Without this quirk, the touchpad is not responsive on this product, with
the following message repeated in the logs:

 psmouse serio1: bad data from KBC - timeout

Add it to the notimeout list alongside other similar Fujitsu laptops.

Signed-off-by: Daniel Drake &lt;drake@endlessm.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.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 817ae460c784f32cd45e60b2b1b21378c3c6a847 upstream.

Without this quirk, the touchpad is not responsive on this product, with
the following message repeated in the logs:

 psmouse serio1: bad data from KBC - timeout

Add it to the notimeout list alongside other similar Fujitsu laptops.

Signed-off-by: Daniel Drake &lt;drake@endlessm.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: ismt: fix wrong device address when unmap the data buffer</title>
<updated>2017-09-15T17:30:11+00:00</updated>
<author>
<name>Liwei Song</name>
<email>liwei.song@windriver.com</email>
</author>
<published>2017-06-13T04:59:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=576c94048c0ea741fc297568850f59b25f776ea1'/>
<id>576c94048c0ea741fc297568850f59b25f776ea1</id>
<content type='text'>
commit 17e83549e199d89aace7788a9f11c108671eecf5 upstream.

Fix the following kernel bug:

kernel BUG at drivers/iommu/intel-iommu.c:3260!
invalid opcode: 0000 [#5] PREEMPT SMP
Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
task: ffff880175389950 ti: ffff880176bec000 task.ti: ffff880176bec000
RIP: 0010:[&lt;ffffffff8150a83b&gt;]  [&lt;ffffffff8150a83b&gt;] intel_unmap+0x25b/0x260
RSP: 0018:ffff880176bef5e8  EFLAGS: 00010296
RAX: 0000000000000024 RBX: ffff8800773c7c88 RCX: 000000000000ce04
RDX: 0000000080000000 RSI: 0000000000000000 RDI: 0000000000000009
RBP: ffff880176bef638 R08: 0000000000000010 R09: 0000000000000004
R10: ffff880175389c78 R11: 0000000000000a4f R12: ffff8800773c7868
R13: 00000000ffffac88 R14: ffff8800773c7818 R15: 0000000000000001
FS:  00007fef21258700(0000) GS:ffff88017b5c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000066d6d8 CR3: 000000007118c000 CR4: 00000000003406e0
Stack:
 00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
 ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
 ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
Call Trace:
 [&lt;ffffffff8199867f&gt;] ? printk+0x46/0x48
 [&lt;ffffffff8150a86e&gt;] intel_unmap_page+0xe/0x10
 [&lt;ffffffffa039d99b&gt;] ismt_access+0x27b/0x8fa [i2c_ismt]
 [&lt;ffffffff81554420&gt;] ? __pm_runtime_suspend+0xa0/0xa0
 [&lt;ffffffff815544a0&gt;] ? pm_suspend_timer_fn+0x80/0x80
 [&lt;ffffffff81554420&gt;] ? __pm_runtime_suspend+0xa0/0xa0
 [&lt;ffffffff815544a0&gt;] ? pm_suspend_timer_fn+0x80/0x80
 [&lt;ffffffff8143dfd0&gt;] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
 [&lt;ffffffff8172b36c&gt;] i2c_smbus_xfer+0xec/0x4b0
 [&lt;ffffffff810aa4d5&gt;] ? vprintk_emit+0x345/0x530
 [&lt;ffffffffa038936b&gt;] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
 [&lt;ffffffff810aa829&gt;] ? vprintk_default+0x29/0x40
 [&lt;ffffffffa0389b33&gt;] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
 [&lt;ffffffff811b04c8&gt;] do_vfs_ioctl+0x328/0x5d0
 [&lt;ffffffff8119d8ec&gt;] ? vfs_write+0x11c/0x190
 [&lt;ffffffff8109d449&gt;] ? rt_up_read+0x19/0x20
 [&lt;ffffffff811b07f1&gt;] SyS_ioctl+0x81/0xa0
 [&lt;ffffffff819a351b&gt;] system_call_fastpath+0x16/0x6e

This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.

After finished I2C block read/write, when unmap the data buffer,
a wrong device address was pass to dma_unmap_single().

To fix this, give dma_unmap_single() the "dev" parameter, just like
what dma_map_single() does, then unmap can find the right devices.

Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
Signed-off-by: Liwei Song &lt;liwei.song@windriver.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&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 17e83549e199d89aace7788a9f11c108671eecf5 upstream.

Fix the following kernel bug:

kernel BUG at drivers/iommu/intel-iommu.c:3260!
invalid opcode: 0000 [#5] PREEMPT SMP
Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
task: ffff880175389950 ti: ffff880176bec000 task.ti: ffff880176bec000
RIP: 0010:[&lt;ffffffff8150a83b&gt;]  [&lt;ffffffff8150a83b&gt;] intel_unmap+0x25b/0x260
RSP: 0018:ffff880176bef5e8  EFLAGS: 00010296
RAX: 0000000000000024 RBX: ffff8800773c7c88 RCX: 000000000000ce04
RDX: 0000000080000000 RSI: 0000000000000000 RDI: 0000000000000009
RBP: ffff880176bef638 R08: 0000000000000010 R09: 0000000000000004
R10: ffff880175389c78 R11: 0000000000000a4f R12: ffff8800773c7868
R13: 00000000ffffac88 R14: ffff8800773c7818 R15: 0000000000000001
FS:  00007fef21258700(0000) GS:ffff88017b5c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000066d6d8 CR3: 000000007118c000 CR4: 00000000003406e0
Stack:
 00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
 ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
 ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
Call Trace:
 [&lt;ffffffff8199867f&gt;] ? printk+0x46/0x48
 [&lt;ffffffff8150a86e&gt;] intel_unmap_page+0xe/0x10
 [&lt;ffffffffa039d99b&gt;] ismt_access+0x27b/0x8fa [i2c_ismt]
 [&lt;ffffffff81554420&gt;] ? __pm_runtime_suspend+0xa0/0xa0
 [&lt;ffffffff815544a0&gt;] ? pm_suspend_timer_fn+0x80/0x80
 [&lt;ffffffff81554420&gt;] ? __pm_runtime_suspend+0xa0/0xa0
 [&lt;ffffffff815544a0&gt;] ? pm_suspend_timer_fn+0x80/0x80
 [&lt;ffffffff8143dfd0&gt;] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
 [&lt;ffffffff8172b36c&gt;] i2c_smbus_xfer+0xec/0x4b0
 [&lt;ffffffff810aa4d5&gt;] ? vprintk_emit+0x345/0x530
 [&lt;ffffffffa038936b&gt;] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
 [&lt;ffffffff810aa829&gt;] ? vprintk_default+0x29/0x40
 [&lt;ffffffffa0389b33&gt;] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
 [&lt;ffffffff811b04c8&gt;] do_vfs_ioctl+0x328/0x5d0
 [&lt;ffffffff8119d8ec&gt;] ? vfs_write+0x11c/0x190
 [&lt;ffffffff8109d449&gt;] ? rt_up_read+0x19/0x20
 [&lt;ffffffff811b07f1&gt;] SyS_ioctl+0x81/0xa0
 [&lt;ffffffff819a351b&gt;] system_call_fastpath+0x16/0x6e

This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.

After finished I2C block read/write, when unmap the data buffer,
a wrong device address was pass to dma_unmap_single().

To fix this, give dma_unmap_single() the "dev" parameter, just like
what dma_map_single() does, then unmap can find the right devices.

Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
Signed-off-by: Liwei Song &lt;liwei.song@windriver.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>IB/ipoib: Fix memory leak in create child syscall</title>
<updated>2017-09-15T17:30:11+00:00</updated>
<author>
<name>Feras Daoud</name>
<email>ferasda@mellanox.com</email>
</author>
<published>2017-06-14T06:59:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ae5212ab18d9691212721243938cb9cd03293adb'/>
<id>ae5212ab18d9691212721243938cb9cd03293adb</id>
<content type='text'>
commit 4542d66bb26f2d021c70a78e46f183c6675fc4c9 upstream.

The flow of creating a new child goes through ipoib_vlan_add
which allocates a new interface and checks the rtnl_lock.

If the lock is taken, restart_syscall will be called to restart
the system call again. In this case we are not releasing the
already allocated interface, causing a leak.

Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Signed-off-by: Feras Daoud &lt;ferasda@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
[bwh: Backported to 3.16: adjust context]
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 4542d66bb26f2d021c70a78e46f183c6675fc4c9 upstream.

The flow of creating a new child goes through ipoib_vlan_add
which allocates a new interface and checks the rtnl_lock.

If the lock is taken, restart_syscall will be called to restart
the system call again. In this case we are not releasing the
already allocated interface, causing a leak.

Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Signed-off-by: Feras Daoud &lt;ferasda@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk</title>
<updated>2017-09-15T17:30:09+00:00</updated>
<author>
<name>Corentin Labbe</name>
<email>clabbe.montjoie@gmail.com</email>
</author>
<published>2017-06-09T11:48:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=18727ff29151a2db3f3e3b2f09b95e3edb86ba1b'/>
<id>18727ff29151a2db3f3e3b2f09b95e3edb86ba1b</id>
<content type='text'>
commit d2f48f05cd2a2a0a708fbfa45f1a00a87660d937 upstream.

When plugging an USB webcam I see the following message:
[106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[106390.583860] handle_tx_event: 913 callbacks suppressed

With this patch applied, I get no more printing of this message.

Signed-off-by: Corentin Labbe &lt;clabbe.montjoie@gmail.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&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 d2f48f05cd2a2a0a708fbfa45f1a00a87660d937 upstream.

When plugging an USB webcam I see the following message:
[106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[106390.583860] handle_tx_event: 913 callbacks suppressed

With this patch applied, I get no more printing of this message.

Signed-off-by: Corentin Labbe &lt;clabbe.montjoie@gmail.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
