<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/lib, branch linux-3.10.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>lib/cmdline.c: fix get_options() overflow while parsing ranges</title>
<updated>2017-11-02T06:16:19+00:00</updated>
<author>
<name>Ilya Matveychikov</name>
<email>matvejchikov@gmail.com</email>
</author>
<published>2017-06-23T22:08:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=303177699c7faa2e27db63c796b8bbba4baeb6ac'/>
<id>303177699c7faa2e27db63c796b8bbba4baeb6ac</id>
<content type='text'>
commit a91e0f680bcd9e10c253ae8b62462a38bd48f09f upstream.

When using get_options() it's possible to specify a range of numbers,
like 1-100500.  The problem is that it doesn't track array size while
calling internally to get_range() which iterates over the range and
fills the memory with numbers.

Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.com
Signed-off-by: Ilya V. Matveychikov &lt;matvejchikov@gmail.com&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&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 a91e0f680bcd9e10c253ae8b62462a38bd48f09f upstream.

When using get_options() it's possible to specify a range of numbers,
like 1-100500.  The problem is that it doesn't track array size while
calling internally to get_range() which iterates over the range and
fills the memory with numbers.

Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.com
Signed-off-by: Ilya V. Matveychikov &lt;matvejchikov@gmail.com&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&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/digsig: fix dereference of NULL user_key_payload</title>
<updated>2017-11-02T06:16:18+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2017-10-09T19:43:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a77cf1b983190f7cefffb5ff5cf358d7944d04b0'/>
<id>a77cf1b983190f7cefffb5ff5cf358d7944d04b0</id>
<content type='text'>
commit 192cabd6a296cbc57b3d8c05c4c89d87fc102506 upstream.

digsig_verify() requests a user key, then accesses its payload.
However, a revoked key has a NULL payload, and we failed to check for
this.  request_key() *does* skip revoked keys, but there is still a
window where the key can be revoked before we acquire its semaphore.

Fix it by checking for a NULL payload, treating it like a key which was
already revoked at the time it was requested.

Fixes: 051dbb918c7f ("crypto: digital signature verification support")
Reviewed-by: James Morris &lt;james.l.morris@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;    [v3.3+]
Cc: Dmitry Kasatkin &lt;dmitry.kasatkin@intel.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&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 192cabd6a296cbc57b3d8c05c4c89d87fc102506 upstream.

digsig_verify() requests a user key, then accesses its payload.
However, a revoked key has a NULL payload, and we failed to check for
this.  request_key() *does* skip revoked keys, but there is still a
window where the key can be revoked before we acquire its semaphore.

Fix it by checking for a NULL payload, treating it like a key which was
already revoked at the time it was requested.

Fixes: 051dbb918c7f ("crypto: digital signature verification support")
Reviewed-by: James Morris &lt;james.l.morris@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;    [v3.3+]
Cc: Dmitry Kasatkin &lt;dmitry.kasatkin@intel.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]</title>
<updated>2017-02-10T10:04:07+00:00</updated>
<author>
<name>Andrey Ryabinin</name>
<email>aryabinin@virtuozzo.com</email>
</author>
<published>2016-11-24T13:23:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=940d1175de7c31e8e2ac20489b7d2df4963bb4da'/>
<id>940d1175de7c31e8e2ac20489b7d2df4963bb4da</id>
<content type='text'>
commit f5527fffff3f002b0a6b376163613b82f69de073 upstream.

This fixes CVE-2016-8650.

If mpi_powm() is given a zero exponent, it wants to immediately return
either 1 or 0, depending on the modulus.  However, if the result was
initalised with zero limb space, no limbs space is allocated and a
NULL-pointer exception ensues.

Fix this by allocating a minimal amount of limb space for the result when
the 0-exponent case when the result is 1 and not touching the limb space
when the result is 0.

This affects the use of RSA keys and X.509 certificates that carry them.

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [&lt;ffffffff8138ce5d&gt;] mpi_powm+0x32/0x7e6
PGD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 3 PID: 3014 Comm: keyctl Not tainted 4.9.0-rc6-fscache+ #278
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
task: ffff8804011944c0 task.stack: ffff880401294000
RIP: 0010:[&lt;ffffffff8138ce5d&gt;]  [&lt;ffffffff8138ce5d&gt;] mpi_powm+0x32/0x7e6
RSP: 0018:ffff880401297ad8  EFLAGS: 00010212
RAX: 0000000000000000 RBX: ffff88040868bec0 RCX: ffff88040868bba0
RDX: ffff88040868b260 RSI: ffff88040868bec0 RDI: ffff88040868bee0
RBP: ffff880401297ba8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000047 R11: ffffffff8183b210 R12: 0000000000000000
R13: ffff8804087c7600 R14: 000000000000001f R15: ffff880401297c50
FS:  00007f7a7918c700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000401250000 CR4: 00000000001406e0
Stack:
 ffff88040868bec0 0000000000000020 ffff880401297b00 ffffffff81376cd4
 0000000000000100 ffff880401297b10 ffffffff81376d12 ffff880401297b30
 ffffffff81376f37 0000000000000100 0000000000000000 ffff880401297ba8
Call Trace:
 [&lt;ffffffff81376cd4&gt;] ? __sg_page_iter_next+0x43/0x66
 [&lt;ffffffff81376d12&gt;] ? sg_miter_get_next_page+0x1b/0x5d
 [&lt;ffffffff81376f37&gt;] ? sg_miter_next+0x17/0xbd
 [&lt;ffffffff8138ba3a&gt;] ? mpi_read_raw_from_sgl+0xf2/0x146
 [&lt;ffffffff8132a95c&gt;] rsa_verify+0x9d/0xee
 [&lt;ffffffff8132acca&gt;] ? pkcs1pad_sg_set_buf+0x2e/0xbb
 [&lt;ffffffff8132af40&gt;] pkcs1pad_verify+0xc0/0xe1
 [&lt;ffffffff8133cb5e&gt;] public_key_verify_signature+0x1b0/0x228
 [&lt;ffffffff8133d974&gt;] x509_check_for_self_signed+0xa1/0xc4
 [&lt;ffffffff8133cdde&gt;] x509_cert_parse+0x167/0x1a1
 [&lt;ffffffff8133d609&gt;] x509_key_preparse+0x21/0x1a1
 [&lt;ffffffff8133c3d7&gt;] asymmetric_key_preparse+0x34/0x61
 [&lt;ffffffff812fc9f3&gt;] key_create_or_update+0x145/0x399
 [&lt;ffffffff812fe227&gt;] SyS_add_key+0x154/0x19e
 [&lt;ffffffff81001c2b&gt;] do_syscall_64+0x80/0x191
 [&lt;ffffffff816825e4&gt;] entry_SYSCALL64_slow_path+0x25/0x25
Code: 56 41 55 41 54 53 48 81 ec a8 00 00 00 44 8b 71 04 8b 42 04 4c 8b 67 18 45 85 f6 89 45 80 0f 84 b4 06 00 00 85 c0 75 2f 41 ff ce &lt;49&gt; c7 04 24 01 00 00 00 b0 01 75 0b 48 8b 41 18 48 83 38 01 0f
RIP  [&lt;ffffffff8138ce5d&gt;] mpi_powm+0x32/0x7e6
 RSP &lt;ffff880401297ad8&gt;
CR2: 0000000000000000
---[ end trace d82015255d4a5d8d ]---

Basically, this is a backport of a libgcrypt patch:

	http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526

Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)")
Signed-off-by: Andrey Ryabinin &lt;aryabinin@virtuozzo.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Dmitry Kasatkin &lt;dmitry.kasatkin@gmail.com&gt;
cc: linux-ima-devel@lists.sourceforge.net
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&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 f5527fffff3f002b0a6b376163613b82f69de073 upstream.

This fixes CVE-2016-8650.

If mpi_powm() is given a zero exponent, it wants to immediately return
either 1 or 0, depending on the modulus.  However, if the result was
initalised with zero limb space, no limbs space is allocated and a
NULL-pointer exception ensues.

Fix this by allocating a minimal amount of limb space for the result when
the 0-exponent case when the result is 1 and not touching the limb space
when the result is 0.

This affects the use of RSA keys and X.509 certificates that carry them.

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [&lt;ffffffff8138ce5d&gt;] mpi_powm+0x32/0x7e6
PGD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 3 PID: 3014 Comm: keyctl Not tainted 4.9.0-rc6-fscache+ #278
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
task: ffff8804011944c0 task.stack: ffff880401294000
RIP: 0010:[&lt;ffffffff8138ce5d&gt;]  [&lt;ffffffff8138ce5d&gt;] mpi_powm+0x32/0x7e6
RSP: 0018:ffff880401297ad8  EFLAGS: 00010212
RAX: 0000000000000000 RBX: ffff88040868bec0 RCX: ffff88040868bba0
RDX: ffff88040868b260 RSI: ffff88040868bec0 RDI: ffff88040868bee0
RBP: ffff880401297ba8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000047 R11: ffffffff8183b210 R12: 0000000000000000
R13: ffff8804087c7600 R14: 000000000000001f R15: ffff880401297c50
FS:  00007f7a7918c700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000401250000 CR4: 00000000001406e0
Stack:
 ffff88040868bec0 0000000000000020 ffff880401297b00 ffffffff81376cd4
 0000000000000100 ffff880401297b10 ffffffff81376d12 ffff880401297b30
 ffffffff81376f37 0000000000000100 0000000000000000 ffff880401297ba8
Call Trace:
 [&lt;ffffffff81376cd4&gt;] ? __sg_page_iter_next+0x43/0x66
 [&lt;ffffffff81376d12&gt;] ? sg_miter_get_next_page+0x1b/0x5d
 [&lt;ffffffff81376f37&gt;] ? sg_miter_next+0x17/0xbd
 [&lt;ffffffff8138ba3a&gt;] ? mpi_read_raw_from_sgl+0xf2/0x146
 [&lt;ffffffff8132a95c&gt;] rsa_verify+0x9d/0xee
 [&lt;ffffffff8132acca&gt;] ? pkcs1pad_sg_set_buf+0x2e/0xbb
 [&lt;ffffffff8132af40&gt;] pkcs1pad_verify+0xc0/0xe1
 [&lt;ffffffff8133cb5e&gt;] public_key_verify_signature+0x1b0/0x228
 [&lt;ffffffff8133d974&gt;] x509_check_for_self_signed+0xa1/0xc4
 [&lt;ffffffff8133cdde&gt;] x509_cert_parse+0x167/0x1a1
 [&lt;ffffffff8133d609&gt;] x509_key_preparse+0x21/0x1a1
 [&lt;ffffffff8133c3d7&gt;] asymmetric_key_preparse+0x34/0x61
 [&lt;ffffffff812fc9f3&gt;] key_create_or_update+0x145/0x399
 [&lt;ffffffff812fe227&gt;] SyS_add_key+0x154/0x19e
 [&lt;ffffffff81001c2b&gt;] do_syscall_64+0x80/0x191
 [&lt;ffffffff816825e4&gt;] entry_SYSCALL64_slow_path+0x25/0x25
Code: 56 41 55 41 54 53 48 81 ec a8 00 00 00 44 8b 71 04 8b 42 04 4c 8b 67 18 45 85 f6 89 45 80 0f 84 b4 06 00 00 85 c0 75 2f 41 ff ce &lt;49&gt; c7 04 24 01 00 00 00 b0 01 75 0b 48 8b 41 18 48 83 38 01 0f
RIP  [&lt;ffffffff8138ce5d&gt;] mpi_powm+0x32/0x7e6
 RSP &lt;ffff880401297ad8&gt;
CR2: 0000000000000000
---[ end trace d82015255d4a5d8d ]---

Basically, this is a backport of a libgcrypt patch:

	http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526

Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)")
Signed-off-by: Andrey Ryabinin &lt;aryabinin@virtuozzo.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Dmitry Kasatkin &lt;dmitry.kasatkin@gmail.com&gt;
cc: linux-ima-devel@lists.sourceforge.net
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ratelimit: fix bug in time interval by resetting right begin time</title>
<updated>2017-02-10T10:04:00+00:00</updated>
<author>
<name>Jaewon Kim</name>
<email>jaewon31.kim@samsung.com</email>
</author>
<published>2016-01-22T00:55:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=479ce88b0d2a0abe07d9c8da8cf80a5eef626831'/>
<id>479ce88b0d2a0abe07d9c8da8cf80a5eef626831</id>
<content type='text'>
commit c2594bc37f4464bc74f2c119eb3269a643400aa0 upstream.

rs-&gt;begin in ratelimit is set in two cases.
 1) when rs-&gt;begin was not initialized
 2) when rs-&gt;interval was passed

For case #2, current ratelimit sets the begin to 0.  This incurrs
improper suppression.  The begin value will be set in the next ratelimit
call by 1).  Then the time interval check will be always false, and
rs-&gt;printed will not be initialized.  Although enough time passed,
ratelimit may return 0 if rs-&gt;printed is not less than rs-&gt;burst.  To
reset interval properly, begin should be jiffies rather than 0.

For an example code below:

    static DEFINE_RATELIMIT_STATE(mylimit, 1, 1);
    for (i = 1; i &lt;= 10; i++) {
        if (__ratelimit(&amp;mylimit))
            printk("ratelimit test count %d\n", i);
        msleep(3000);
    }

test result in the current code shows suppression even there is 3 seconds sleep.

  [  78.391148] ratelimit test count 1
  [  81.295988] ratelimit test count 2
  [  87.315981] ratelimit test count 4
  [  93.336267] ratelimit test count 6
  [  99.356031] ratelimit test count 8
  [ 105.376367] ratelimit test count 10

Signed-off-by: Jaewon Kim &lt;jaewon31.kim@samsung.com&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 c2594bc37f4464bc74f2c119eb3269a643400aa0 upstream.

rs-&gt;begin in ratelimit is set in two cases.
 1) when rs-&gt;begin was not initialized
 2) when rs-&gt;interval was passed

For case #2, current ratelimit sets the begin to 0.  This incurrs
improper suppression.  The begin value will be set in the next ratelimit
call by 1).  Then the time interval check will be always false, and
rs-&gt;printed will not be initialized.  Although enough time passed,
ratelimit may return 0 if rs-&gt;printed is not less than rs-&gt;burst.  To
reset interval properly, begin should be jiffies rather than 0.

For an example code below:

    static DEFINE_RATELIMIT_STATE(mylimit, 1, 1);
    for (i = 1; i &lt;= 10; i++) {
        if (__ratelimit(&amp;mylimit))
            printk("ratelimit test count %d\n", i);
        msleep(3000);
    }

test result in the current code shows suppression even there is 3 seconds sleep.

  [  78.391148] ratelimit test count 1
  [  81.295988] ratelimit test count 2
  [  87.315981] ratelimit test count 4
  [  93.336267] ratelimit test count 6
  [  99.356031] ratelimit test count 8
  [ 105.376367] ratelimit test count 10

Signed-off-by: Jaewon Kim &lt;jaewon31.kim@samsung.com&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/genalloc.c: start search from start of chunk</title>
<updated>2017-02-10T10:03:59+00:00</updated>
<author>
<name>Daniel Mentz</name>
<email>danielmentz@google.com</email>
</author>
<published>2016-10-28T00:46:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f98c2c402949fe2834a8291662c92c4ab5122273'/>
<id>f98c2c402949fe2834a8291662c92c4ab5122273</id>
<content type='text'>
commit 62e931fac45b17c2a42549389879411572f75804 upstream.

gen_pool_alloc_algo() iterates over the chunks of a pool trying to find
a contiguous block of memory that satisfies the allocation request.

The shortcut

	if (size &gt; atomic_read(&amp;chunk-&gt;avail))
		continue;

makes the loop skip over chunks that do not have enough bytes left to
fulfill the request.  There are two situations, though, where an
allocation might still fail:

(1) The available memory is not contiguous, i.e.  the request cannot
    be fulfilled due to external fragmentation.

(2) A race condition.  Another thread runs the same code concurrently
    and is quicker to grab the available memory.

In those situations, the loop calls pool-&gt;algo() to search the entire
chunk, and pool-&gt;algo() returns some value that is &gt;= end_bit to
indicate that the search failed.  This return value is then assigned to
start_bit.  The variables start_bit and end_bit describe the range that
should be searched, and this range should be reset for every chunk that
is searched.  Today, the code fails to reset start_bit to 0.  As a
result, prefixes of subsequent chunks are ignored.  Memory allocations
might fail even though there is plenty of room left in these prefixes of
those other chunks.

Fixes: 7f184275aa30 ("lib, Make gen_pool memory allocator lockless")
Link: http://lkml.kernel.org/r/1477420604-28918-1-git-send-email-danielmentz@google.com
Signed-off-by: Daniel Mentz &lt;danielmentz@google.com&gt;
Reviewed-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&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 62e931fac45b17c2a42549389879411572f75804 upstream.

gen_pool_alloc_algo() iterates over the chunks of a pool trying to find
a contiguous block of memory that satisfies the allocation request.

The shortcut

	if (size &gt; atomic_read(&amp;chunk-&gt;avail))
		continue;

makes the loop skip over chunks that do not have enough bytes left to
fulfill the request.  There are two situations, though, where an
allocation might still fail:

(1) The available memory is not contiguous, i.e.  the request cannot
    be fulfilled due to external fragmentation.

(2) A race condition.  Another thread runs the same code concurrently
    and is quicker to grab the available memory.

In those situations, the loop calls pool-&gt;algo() to search the entire
chunk, and pool-&gt;algo() returns some value that is &gt;= end_bit to
indicate that the search failed.  This return value is then assigned to
start_bit.  The variables start_bit and end_bit describe the range that
should be searched, and this range should be reset for every chunk that
is searched.  Today, the code fails to reset start_bit to 0.  As a
result, prefixes of subsequent chunks are ignored.  Memory allocations
might fail even though there is plenty of room left in these prefixes of
those other chunks.

Fixes: 7f184275aa30 ("lib, Make gen_pool memory allocator lockless")
Link: http://lkml.kernel.org/r/1477420604-28918-1-git-send-email-danielmentz@google.com
Signed-off-by: Daniel Mentz &lt;danielmentz@google.com&gt;
Reviewed-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&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>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.tavy.me/linux-stable.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.tavy.me/linux-stable.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.tavy.me/linux-stable.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.tavy.me/linux-stable.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.tavy.me/linux-stable.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>
</feed>
