<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/lib, branch v3.10.103</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>dma-debug: avoid spinlock recursion when disabling dma-debug</title>
<updated>2016-08-21T21:22:50+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2016-05-26T22:16:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=0ed4547f527c1410ff2a35af766ce5c3a29405c4'/>
<id>0ed4547f527c1410ff2a35af766ce5c3a29405c4</id>
<content type='text'>
commit 3017cd63f26fc655d56875aaf497153ba60e9edf upstream.

With netconsole (at least) the pr_err("...  disablingn") call can
recurse back into the dma-debug code, where it'll try to grab
free_entries_lock again.  Avoid the problem by doing the printk after
dropping the lock.

Link: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3017cd63f26fc655d56875aaf497153ba60e9edf upstream.

With netconsole (at least) the pr_err("...  disablingn") call can
recurse back into the dma-debug code, where it'll try to grab
free_entries_lock again.  Avoid the problem by doing the printk after
dropping the lock.

Link: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lib/ucs2_string: Correct ucs2 -&gt; utf8 conversion</title>
<updated>2016-03-16T15:41:37+00:00</updated>
<author>
<name>Jason Andryuk</name>
<email>jandryuk@gmail.com</email>
</author>
<published>2016-02-12T23:13:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c8bedaa47abfc566933d5c0c96c39bee95cb0deb'/>
<id>c8bedaa47abfc566933d5c0c96c39bee95cb0deb</id>
<content type='text'>
commit a68075908a37850918ad96b056acc9ac4ce1bd90 upstream.

The comparisons should be &gt;= since 0x800 and 0x80 require an additional bit
to store.

For the 3 byte case, the existing shift would drop off 2 more bits than
intended.

For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
byte 2.

Signed-off-by: Jason Andryuk &lt;jandryuk@gmail.com&gt;
Reviewed-by: Laszlo Ersek &lt;lersek@redhat.com&gt;
Cc: Peter Jones &lt;pjones@redhat.com&gt;
Cc: Matthew Garrett &lt;mjg59@coreos.com&gt;
Cc: "Lee, Chun-Yi" &lt;jlee@suse.com&gt;
Signed-off-by: Matt Fleming &lt;matt@codeblueprint.co.uk&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 a68075908a37850918ad96b056acc9ac4ce1bd90 upstream.

The comparisons should be &gt;= since 0x800 and 0x80 require an additional bit
to store.

For the 3 byte case, the existing shift would drop off 2 more bits than
intended.

For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
byte 2.

Signed-off-by: Jason Andryuk &lt;jandryuk@gmail.com&gt;
Reviewed-by: Laszlo Ersek &lt;lersek@redhat.com&gt;
Cc: Peter Jones &lt;pjones@redhat.com&gt;
Cc: Matthew Garrett &lt;mjg59@coreos.com&gt;
Cc: "Lee, Chun-Yi" &lt;jlee@suse.com&gt;
Signed-off-by: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>lib/ucs2_string: Add ucs2 -&gt; utf8 helper functions</title>
<updated>2016-03-16T15:41:36+00:00</updated>
<author>
<name>Peter Jones</name>
<email>pjones@redhat.com</email>
</author>
<published>2016-02-08T19:48:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f0b5aae480e53e26c0739241144eaa0e2e56a4fc'/>
<id>f0b5aae480e53e26c0739241144eaa0e2e56a4fc</id>
<content type='text'>
commit 73500267c930baadadb0d02284909731baf151f7 upstream.

This adds ucs2_utf8size(), which tells us how big our ucs2 string is in
bytes, and ucs2_as_utf8, which translates from ucs2 to utf8..

Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
Tested-by: Lee, Chun-Yi &lt;jlee@suse.com&gt;
Acked-by: Matthew Garrett &lt;mjg59@coreos.com&gt;
Signed-off-by: Matt Fleming &lt;matt@codeblueprint.co.uk&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 73500267c930baadadb0d02284909731baf151f7 upstream.

This adds ucs2_utf8size(), which tells us how big our ucs2 string is in
bytes, and ucs2_as_utf8, which translates from ucs2 to utf8..

Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
Tested-by: Lee, Chun-Yi &lt;jlee@suse.com&gt;
Acked-by: Matthew Garrett &lt;mjg59@coreos.com&gt;
Signed-off-by: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>devres: fix a for loop bounds check</title>
<updated>2016-03-03T23:06:20+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2015-09-21T16:21:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=736652169c60e99df027befd07f9217bcaba840d'/>
<id>736652169c60e99df027befd07f9217bcaba840d</id>
<content type='text'>
commit 1f35d04a02a652f14566f875aef3a6f2af4cb77b upstream.

The iomap[] array has PCIM_IOMAP_MAX (6) elements and not
DEVICE_COUNT_RESOURCE (16).  This bug was found using a static checker.
It may be that the "if (!(mask &amp; (1 &lt;&lt; i)))" check means we never
actually go past the end of the array in real life.

Fixes: ec04b075843d ('iomap: implement pcim_iounmap_regions()')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&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 1f35d04a02a652f14566f875aef3a6f2af4cb77b upstream.

The iomap[] array has PCIM_IOMAP_MAX (6) elements and not
DEVICE_COUNT_RESOURCE (16).  This bug was found using a static checker.
It may be that the "if (!(mask &amp; (1 &lt;&lt; i)))" check means we never
actually go past the end of the array in real life.

Fixes: ec04b075843d ('iomap: implement pcim_iounmap_regions()')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>radix-tree: fix race in gang lookup</title>
<updated>2016-02-25T19:57:49+00:00</updated>
<author>
<name>Matthew Wilcox</name>
<email>willy@linux.intel.com</email>
</author>
<published>2016-02-03T00:57:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=a202017766a111064dc0a99ee38d85886816b27a'/>
<id>a202017766a111064dc0a99ee38d85886816b27a</id>
<content type='text'>
commit 46437f9a554fbe3e110580ca08ab703b59f2f95a upstream.

If the indirect_ptr bit is set on a slot, that indicates we need to redo
the lookup.  Introduce a new function radix_tree_iter_retry() which
forces the loop to retry the lookup by setting 'slot' to NULL and
turning the iterator back to point at the problematic entry.

This is a pretty rare problem to hit at the moment; the lookup has to
race with a grow of the radix tree from a height of 0.  The consequences
of hitting this race are that gang lookup could return a pointer to a
radix_tree_node instead of a pointer to whatever the user had inserted
in the tree.

Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator")
Signed-off-by: Matthew Wilcox &lt;willy@linux.intel.com&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Ohad Ben-Cohen &lt;ohad@wizery.com&gt;
Cc: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&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 46437f9a554fbe3e110580ca08ab703b59f2f95a upstream.

If the indirect_ptr bit is set on a slot, that indicates we need to redo
the lookup.  Introduce a new function radix_tree_iter_retry() which
forces the loop to retry the lookup by setting 'slot' to NULL and
turning the iterator back to point at the problematic entry.

This is a pretty rare problem to hit at the moment; the lookup has to
race with a grow of the radix tree from a height of 0.  The consequences
of hitting this race are that gang lookup could return a pointer to a
radix_tree_node instead of a pointer to whatever the user had inserted
in the tree.

Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator")
Signed-off-by: Matthew Wilcox &lt;willy@linux.intel.com&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Ohad Ben-Cohen &lt;ohad@wizery.com&gt;
Cc: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>dma-debug: switch check from _text to _stext</title>
<updated>2016-02-25T19:57:49+00:00</updated>
<author>
<name>Laura Abbott</name>
<email>labbott@fedoraproject.org</email>
</author>
<published>2016-01-14T23:16:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2942425f64895dead4dfe46462e00c9871c2bc12'/>
<id>2942425f64895dead4dfe46462e00c9871c2bc12</id>
<content type='text'>
commit ea535e418c01837d07b6c94e817540f50bfdadb0 upstream.

In include/asm-generic/sections.h:

  /*
   * Usage guidelines:
   * _text, _data: architecture specific, don't use them in
   * arch-independent code
   * [_stext, _etext]: contains .text.* sections, may also contain
   * .rodata.*
   *                   and/or .init.* sections

_text is not guaranteed across architectures.  Architectures such as ARM
may reuse parts which are not actually text and erroneously trigger a bug.
Switch to using _stext which is guaranteed to contain text sections.

Came out of https://lkml.kernel.org/g/&lt;567B1176.4000106@redhat.com&gt;

Signed-off-by: Laura Abbott &lt;labbott@fedoraproject.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&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 ea535e418c01837d07b6c94e817540f50bfdadb0 upstream.

In include/asm-generic/sections.h:

  /*
   * Usage guidelines:
   * _text, _data: architecture specific, don't use them in
   * arch-independent code
   * [_stext, _etext]: contains .text.* sections, may also contain
   * .rodata.*
   *                   and/or .init.* sections

_text is not guaranteed across architectures.  Architectures such as ARM
may reuse parts which are not actually text and erroneously trigger a bug.
Switch to using _stext which is guaranteed to contain text sections.

Came out of https://lkml.kernel.org/g/&lt;567B1176.4000106@redhat.com&gt;

Signed-off-by: Laura Abbott &lt;labbott@fedoraproject.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>klist: fix starting point removed bug in klist iterators</title>
<updated>2016-02-25T19:57:47+00:00</updated>
<author>
<name>James Bottomley</name>
<email>James.Bottomley@HansenPartnership.com</email>
</author>
<published>2016-01-13T16:10:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=00707985578715324f32a0d71dbf6221bc4a2fc7'/>
<id>00707985578715324f32a0d71dbf6221bc4a2fc7</id>
<content type='text'>
commit 00cd29b799e3449f0c68b1cc77cd4a5f95b42d17 upstream.

The starting node for a klist iteration is often passed in from
somewhere way above the klist infrastructure, meaning there's no
guarantee the node is still on the list.  We've seen this in SCSI where
we use bus_find_device() to iterate through a list of devices.  In the
face of heavy hotplug activity, the last device returned by
bus_find_device() can be removed before the next call.  This leads to

Dec  3 13:22:02 localhost kernel: WARNING: CPU: 2 PID: 28073 at include/linux/kref.h:47 klist_iter_init_node+0x3d/0x50()
Dec  3 13:22:02 localhost kernel: Modules linked in: scsi_debug x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel joydev iTCO_wdt dcdbas ipmi_devintf acpi_power_meter iTCO_vendor_support ipmi_si imsghandler pcspkr wmi acpi_cpufreq tpm_tis tpm shpchp lpc_ich mfd_core nfsd nfs_acl lockd grace sunrpc tg3 ptp pps_core
Dec  3 13:22:02 localhost kernel: CPU: 2 PID: 28073 Comm: cat Not tainted 4.4.0-rc1+ #2
Dec  3 13:22:02 localhost kernel: Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013
Dec  3 13:22:02 localhost kernel: ffffffff81a20e77 ffff880613acfd18 ffffffff81321eef 0000000000000000
Dec  3 13:22:02 localhost kernel: ffff880613acfd50 ffffffff8107ca52 ffff88061176b198 0000000000000000
Dec  3 13:22:02 localhost kernel: ffffffff814542b0 ffff880610cfb100 ffff88061176b198 ffff880613acfd60
Dec  3 13:22:02 localhost kernel: Call Trace:
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff81321eef&gt;] dump_stack+0x44/0x55
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff8107ca52&gt;] warn_slowpath_common+0x82/0xc0
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff814542b0&gt;] ? proc_scsi_show+0x20/0x20
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff8107cb4a&gt;] warn_slowpath_null+0x1a/0x20
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff8167225d&gt;] klist_iter_init_node+0x3d/0x50
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff81421d41&gt;] bus_find_device+0x51/0xb0
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff814545ad&gt;] scsi_seq_next+0x2d/0x40
[...]

And an eventual crash. It can actually occur in any hotplug system
which has a device finder and a starting device.

We can fix this globally by making sure the starting node for
klist_iter_init_node() is actually a member of the list before using it
(and by starting from the beginning if it isn't).

Reported-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Tested-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&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 00cd29b799e3449f0c68b1cc77cd4a5f95b42d17 upstream.

The starting node for a klist iteration is often passed in from
somewhere way above the klist infrastructure, meaning there's no
guarantee the node is still on the list.  We've seen this in SCSI where
we use bus_find_device() to iterate through a list of devices.  In the
face of heavy hotplug activity, the last device returned by
bus_find_device() can be removed before the next call.  This leads to

Dec  3 13:22:02 localhost kernel: WARNING: CPU: 2 PID: 28073 at include/linux/kref.h:47 klist_iter_init_node+0x3d/0x50()
Dec  3 13:22:02 localhost kernel: Modules linked in: scsi_debug x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel joydev iTCO_wdt dcdbas ipmi_devintf acpi_power_meter iTCO_vendor_support ipmi_si imsghandler pcspkr wmi acpi_cpufreq tpm_tis tpm shpchp lpc_ich mfd_core nfsd nfs_acl lockd grace sunrpc tg3 ptp pps_core
Dec  3 13:22:02 localhost kernel: CPU: 2 PID: 28073 Comm: cat Not tainted 4.4.0-rc1+ #2
Dec  3 13:22:02 localhost kernel: Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013
Dec  3 13:22:02 localhost kernel: ffffffff81a20e77 ffff880613acfd18 ffffffff81321eef 0000000000000000
Dec  3 13:22:02 localhost kernel: ffff880613acfd50 ffffffff8107ca52 ffff88061176b198 0000000000000000
Dec  3 13:22:02 localhost kernel: ffffffff814542b0 ffff880610cfb100 ffff88061176b198 ffff880613acfd60
Dec  3 13:22:02 localhost kernel: Call Trace:
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff81321eef&gt;] dump_stack+0x44/0x55
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff8107ca52&gt;] warn_slowpath_common+0x82/0xc0
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff814542b0&gt;] ? proc_scsi_show+0x20/0x20
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff8107cb4a&gt;] warn_slowpath_null+0x1a/0x20
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff8167225d&gt;] klist_iter_init_node+0x3d/0x50
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff81421d41&gt;] bus_find_device+0x51/0xb0
Dec  3 13:22:02 localhost kernel: [&lt;ffffffff814545ad&gt;] scsi_seq_next+0x2d/0x40
[...]

And an eventual crash. It can actually occur in any hotplug system
which has a device finder and a starting device.

We can fix this globally by making sure the starting node for
klist_iter_init_node() is actually a member of the list before using it
(and by starting from the beginning if it isn't).

Reported-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Tested-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>__bitmap_parselist: fix bug in empty string handling</title>
<updated>2015-08-03T16:29:46+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@ezchip.com</email>
</author>
<published>2015-06-25T22:02:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=bf95f46c3f1c3aa7f0cc026241877478487c3670'/>
<id>bf95f46c3f1c3aa7f0cc026241877478487c3670</id>
<content type='text'>
commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 upstream.

bitmap_parselist("", &amp;mask, nmaskbits) will erroneously set bit zero in
the mask.  The same bug is visible in cpumask_parselist() since it is
layered on top of the bitmask code, e.g.  if you boot with "isolcpus=",
you will actually end up with cpu zero isolated.

The bug was introduced in commit 4b060420a596 ("bitmap, irq: add
smp_affinity_list interface to /proc/irq") when bitmap_parselist() was
generalized to support userspace as well as kernelspace.

Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
Signed-off-by: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Rasmus Villemoes &lt;linux@rasmusvillemoes.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&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 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 upstream.

bitmap_parselist("", &amp;mask, nmaskbits) will erroneously set bit zero in
the mask.  The same bug is visible in cpumask_parselist() since it is
layered on top of the bitmask code, e.g.  if you boot with "isolcpus=",
you will actually end up with cpu zero isolated.

The bug was introduced in commit 4b060420a596 ("bitmap, irq: add
smp_affinity_list interface to /proc/irq") when bitmap_parselist() was
generalized to support userspace as well as kernelspace.

Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
Signed-off-by: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Rasmus Villemoes &lt;linux@rasmusvillemoes.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>lib: Fix strnlen_user() to not touch memory after specified maximum</title>
<updated>2015-06-06T06:19:54+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2015-06-02T15:10:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=73f668104f25d364f758e8c6738c2a1826d2f0fc'/>
<id>73f668104f25d364f758e8c6738c2a1826d2f0fc</id>
<content type='text'>
commit f18c34e483ff6b1d9866472221e4015b3a4698e4 upstream.

If the specified maximum length of the string is a multiple of unsigned
long, we would load one long behind the specified maximum.  If that
happens to be in a next page, we can hit a page fault although we were
not expected to.

Fix the off-by-one bug in the test whether we are at the end of the
specified range.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&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 f18c34e483ff6b1d9866472221e4015b3a4698e4 upstream.

If the specified maximum length of the string is a multiple of unsigned
long, we would load one long behind the specified maximum.  If that
happens to be in a next page, we can hit a page fault although we were
not expected to.

Fix the off-by-one bug in the test whether we are at the end of the
specified range.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR</title>
<updated>2015-05-06T19:56:28+00:00</updated>
<author>
<name>mancha security</name>
<email>mancha1@zoho.com</email>
</author>
<published>2015-03-18T17:47:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e60e4dc082ca9c63d2113be4be5ac4cf3fd2f2a8'/>
<id>e60e4dc082ca9c63d2113be4be5ac4cf3fd2f2a8</id>
<content type='text'>
commit 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream.

OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
ensure protection from dead store optimization.

For the random driver and crypto drivers, calls are emitted ...

  $ gdb vmlinux
  (gdb) disassemble memzero_explicit
  Dump of assembler code for function memzero_explicit:
    0xffffffff813a18b0 &lt;+0&gt;:	push   %rbp
    0xffffffff813a18b1 &lt;+1&gt;:	mov    %rsi,%rdx
    0xffffffff813a18b4 &lt;+4&gt;:	xor    %esi,%esi
    0xffffffff813a18b6 &lt;+6&gt;:	mov    %rsp,%rbp
    0xffffffff813a18b9 &lt;+9&gt;:	callq  0xffffffff813a7120 &lt;memset&gt;
    0xffffffff813a18be &lt;+14&gt;:	pop    %rbp
    0xffffffff813a18bf &lt;+15&gt;:	retq
  End of assembler dump.

  (gdb) disassemble extract_entropy
  [...]
    0xffffffff814a5009 &lt;+313&gt;:	mov    %r12,%rdi
    0xffffffff814a500c &lt;+316&gt;:	mov    $0xa,%esi
    0xffffffff814a5011 &lt;+321&gt;:	callq  0xffffffff813a18b0 &lt;memzero_explicit&gt;
    0xffffffff814a5016 &lt;+326&gt;:	mov    -0x48(%rbp),%rax
  [...]

... but in case in future we might use facilities such as LTO, then
OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible
eviction of the memset(). We have to use a compiler barrier instead.

Minimal test example when we assume memzero_explicit() would *not* be
a call, but would have been *inlined* instead:

  static inline void memzero_explicit(void *s, size_t count)
  {
    memset(s, 0, count);
    &lt;foo&gt;
  }

  int main(void)
  {
    char buff[20];

    snprintf(buff, sizeof(buff) - 1, "test");
    printf("%s", buff);

    memzero_explicit(buff, sizeof(buff));
    return 0;
  }

With &lt;foo&gt; := OPTIMIZER_HIDE_VAR():

  (gdb) disassemble main
  Dump of assembler code for function main:
  [...]
   0x0000000000400464 &lt;+36&gt;:	callq  0x400410 &lt;printf@plt&gt;
   0x0000000000400469 &lt;+41&gt;:	xor    %eax,%eax
   0x000000000040046b &lt;+43&gt;:	add    $0x28,%rsp
   0x000000000040046f &lt;+47&gt;:	retq
  End of assembler dump.

With &lt;foo&gt; := barrier():

  (gdb) disassemble main
  Dump of assembler code for function main:
  [...]
   0x0000000000400464 &lt;+36&gt;:	callq  0x400410 &lt;printf@plt&gt;
   0x0000000000400469 &lt;+41&gt;:	movq   $0x0,(%rsp)
   0x0000000000400471 &lt;+49&gt;:	movq   $0x0,0x8(%rsp)
   0x000000000040047a &lt;+58&gt;:	movl   $0x0,0x10(%rsp)
   0x0000000000400482 &lt;+66&gt;:	xor    %eax,%eax
   0x0000000000400484 &lt;+68&gt;:	add    $0x28,%rsp
   0x0000000000400488 &lt;+72&gt;:	retq
  End of assembler dump.

As can be seen, movq, movq, movl are being emitted inlined
via memset().

Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/
Fixes: d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data")
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: mancha security &lt;mancha1@zoho.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Stephan Mueller &lt;smueller@chronox.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&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 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream.

OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
ensure protection from dead store optimization.

For the random driver and crypto drivers, calls are emitted ...

  $ gdb vmlinux
  (gdb) disassemble memzero_explicit
  Dump of assembler code for function memzero_explicit:
    0xffffffff813a18b0 &lt;+0&gt;:	push   %rbp
    0xffffffff813a18b1 &lt;+1&gt;:	mov    %rsi,%rdx
    0xffffffff813a18b4 &lt;+4&gt;:	xor    %esi,%esi
    0xffffffff813a18b6 &lt;+6&gt;:	mov    %rsp,%rbp
    0xffffffff813a18b9 &lt;+9&gt;:	callq  0xffffffff813a7120 &lt;memset&gt;
    0xffffffff813a18be &lt;+14&gt;:	pop    %rbp
    0xffffffff813a18bf &lt;+15&gt;:	retq
  End of assembler dump.

  (gdb) disassemble extract_entropy
  [...]
    0xffffffff814a5009 &lt;+313&gt;:	mov    %r12,%rdi
    0xffffffff814a500c &lt;+316&gt;:	mov    $0xa,%esi
    0xffffffff814a5011 &lt;+321&gt;:	callq  0xffffffff813a18b0 &lt;memzero_explicit&gt;
    0xffffffff814a5016 &lt;+326&gt;:	mov    -0x48(%rbp),%rax
  [...]

... but in case in future we might use facilities such as LTO, then
OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible
eviction of the memset(). We have to use a compiler barrier instead.

Minimal test example when we assume memzero_explicit() would *not* be
a call, but would have been *inlined* instead:

  static inline void memzero_explicit(void *s, size_t count)
  {
    memset(s, 0, count);
    &lt;foo&gt;
  }

  int main(void)
  {
    char buff[20];

    snprintf(buff, sizeof(buff) - 1, "test");
    printf("%s", buff);

    memzero_explicit(buff, sizeof(buff));
    return 0;
  }

With &lt;foo&gt; := OPTIMIZER_HIDE_VAR():

  (gdb) disassemble main
  Dump of assembler code for function main:
  [...]
   0x0000000000400464 &lt;+36&gt;:	callq  0x400410 &lt;printf@plt&gt;
   0x0000000000400469 &lt;+41&gt;:	xor    %eax,%eax
   0x000000000040046b &lt;+43&gt;:	add    $0x28,%rsp
   0x000000000040046f &lt;+47&gt;:	retq
  End of assembler dump.

With &lt;foo&gt; := barrier():

  (gdb) disassemble main
  Dump of assembler code for function main:
  [...]
   0x0000000000400464 &lt;+36&gt;:	callq  0x400410 &lt;printf@plt&gt;
   0x0000000000400469 &lt;+41&gt;:	movq   $0x0,(%rsp)
   0x0000000000400471 &lt;+49&gt;:	movq   $0x0,0x8(%rsp)
   0x000000000040047a &lt;+58&gt;:	movl   $0x0,0x10(%rsp)
   0x0000000000400482 &lt;+66&gt;:	xor    %eax,%eax
   0x0000000000400484 &lt;+68&gt;:	add    $0x28,%rsp
   0x0000000000400488 &lt;+72&gt;:	retq
  End of assembler dump.

As can be seen, movq, movq, movl are being emitted inlined
via memset().

Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/
Fixes: d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data")
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: mancha security &lt;mancha1@zoho.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Stephan Mueller &lt;smueller@chronox.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
