<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/lib, branch v4.4.22</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.22</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.22'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-09-24T08:07:43+00:00</updated>
<entry>
<title>fix iov_iter_fault_in_readable()</title>
<updated>2016-09-24T08:07:43+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@ZenIV.linux.org.uk</email>
</author>
<published>2016-09-15T23:11:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=99526912c934f848e5dc1065ec6a1c1c33b1a8d1'/>
<id>urn:sha1:99526912c934f848e5dc1065ec6a1c1c33b1a8d1</id>
<content type='text'>
commit d4690f1e1cdabb4d61207b6787b1605a0dc0aeab upstream.

... by turning it into what used to be multipages counterpart

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs</title>
<updated>2016-09-15T06:27:54+00:00</updated>
<author>
<name>Nicolai Stange</name>
<email>nicstange@gmail.com</email>
</author>
<published>2016-03-22T12:12:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=11c27e850d90372d79c1337be299923b5fb353e8'/>
<id>urn:sha1:11c27e850d90372d79c1337be299923b5fb353e8</id>
<content type='text'>
commit f2d1362ff7d266b3d2b1c764d6c2ef4a3b457f23 upstream.

Currently, if the number of leading zeros is greater than fits into a
complete limb, mpi_write_sgl() skips them by iterating over them limb-wise.

However, it fails to adjust its internal leading zeros tracking variable,
lzeros, accordingly: it does a

  p -= sizeof(alimb);
  continue;

which should really have been a

  lzeros -= sizeof(alimb);
  continue;

Since lzeros never decreases if its initial value &gt;= sizeof(alimb), nothing
gets copied by mpi_write_sgl() in that case.

Instead of skipping the high order zero limbs within the loop as shown
above, fix the issue by adjusting the copying loop's bounds.

Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Signed-off-by: Nicolai Stange &lt;nicstange@gmail.com&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>
</entry>
<entry>
<title>KEYS: Fix ASN.1 indefinite length object parsing</title>
<updated>2016-09-15T06:27:50+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2016-08-30T04:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5afbd223e60a130f66bddf7598165ebe2b51f8db'/>
<id>urn:sha1:5afbd223e60a130f66bddf7598165ebe2b51f8db</id>
<content type='text'>
[ Upstream commit 23c8a812dc3c621009e4f0e5342aa4e2ede1ceaa ]

This fixes CVE-2016-0758.

In the ASN.1 decoder, when the length field of an ASN.1 value is extracted,
it isn't validated against the remaining amount of data before being added
to the cursor.  With a sufficiently large size indicated, the check:

	datalen - dp &lt; 2

may then fail due to integer overflow.

Fix this by checking the length indicated against the amount of remaining
data in both places a definite length is determined.

Whilst we're at it, make the following changes:

 (1) Check the maximum size of extended length does not exceed the capacity
     of the variable it's being stored in (len) rather than the type that
     variable is assumed to be (size_t).

 (2) Compare the EOC tag to the symbolic constant ASN1_EOC rather than the
     integer 0.

 (3) To reduce confusion, move the initialisation of len outside of:

	for (len = 0; n &gt; 0; n--) {

     since it doesn't have anything to do with the loop counter n.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Acked-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Acked-by: Peter Jones &lt;pjones@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dma-debug: avoid spinlock recursion when disabling dma-debug</title>
<updated>2016-06-08T01:14:37+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.radix-linux.su/kernel/linux.git/commit/?id=7d0b494532b703da654f96389804f491a6594bbb'/>
<id>urn:sha1:7d0b494532b703da654f96389804f491a6594bbb</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;
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>
</entry>
<entry>
<title>lib/test-string_helpers.c: fix and improve string_get_size() tests</title>
<updated>2016-05-11T09:21:26+00:00</updated>
<author>
<name>Vitaly Kuznetsov</name>
<email>vkuznets@redhat.com</email>
</author>
<published>2016-02-03T00:57:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f6ff7398220d7fda0f4d02b9c9755406d8169bc2'/>
<id>urn:sha1:f6ff7398220d7fda0f4d02b9c9755406d8169bc2</id>
<content type='text'>
commit 72676bb53f33fd0ef3a1484fc1ecfd306dc6ff40 upstream.

Recently added commit 564b026fbd0d ("string_helpers: fix precision loss
for some inputs") fixed precision issues for string_get_size() and broke
tests.

Fix and improve them: test both STRING_UNITS_2 and STRING_UNITS_10 at a
time, better failure reporting, test small an huge values.

Fixes: 564b026fbd0d28e9 ("string_helpers: fix precision loss for some inputs")
Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Rasmus Villemoes &lt;linux@rasmusvillemoes.dk&gt;
Cc: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Cc: James Bottomley &lt;JBottomley@Odin.com&gt;
Cc: "James E.J. Bottomley" &lt;jejb@parisc-linux.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>
</entry>
<entry>
<title>lib/mpi: Endianness fix</title>
<updated>2016-05-04T21:48:51+00:00</updated>
<author>
<name>Michal Marek</name>
<email>mmarek@suse.com</email>
</author>
<published>2016-02-17T13:46:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=81b3a56ed84b0f2c1e2ff75ee2e05d5d4cd2462b'/>
<id>urn:sha1:81b3a56ed84b0f2c1e2ff75ee2e05d5d4cd2462b</id>
<content type='text'>
commit 3ee0cb5fb5eea2110db1b5cb7f67029b7be8a376 upstream.

The limbs are integers in the host endianness, so we can't simply
iterate over the individual bytes. The current code happens to work on
little-endian, because the order of the limbs in the MPI array is the
same as the order of the bytes in each limb, but it breaks on
big-endian.

Fixes: 0f74fbf77d45 ("MPI: Fix mpi_read_buffer")
Signed-off-by: Michal Marek &lt;mmarek@suse.com&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>
</entry>
<entry>
<title>lib: lz4: fixed zram with lz4 on big endian machines</title>
<updated>2016-05-04T21:48:41+00:00</updated>
<author>
<name>Rui Salvaterra</name>
<email>rsalvaterra@gmail.com</email>
</author>
<published>2016-04-09T21:05:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed643d220692bfc2bfec9fe618d102f13a5dae9f'/>
<id>urn:sha1:ed643d220692bfc2bfec9fe618d102f13a5dae9f</id>
<content type='text'>
commit 3e26a691fe3fe1e02a76e5bab0c143ace4b137b4 upstream.

Based on Sergey's test patch [1], this fixes zram with lz4 compression
on big endian cpus.

Note that the 64-bit preprocessor test is not a cleanup, it's part of
the fix, since those identifiers are bogus (for example, __ppc64__
isn't defined anywhere else in the kernel, which means we'd fall into
the 32-bit definitions on ppc64).

Tested on ppc64 with no regression on x86_64.

[1] http://marc.info/?l=linux-kernel&amp;m=145994470805853&amp;w=4

Suggested-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Signed-off-by: Rui Salvaterra &lt;rsalvaterra@gmail.com&gt;
Reviewed-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>assoc_array: don't call compare_object() on a node</title>
<updated>2016-05-04T21:48:40+00:00</updated>
<author>
<name>Jerome Marchand</name>
<email>jmarchan@redhat.com</email>
</author>
<published>2016-04-06T13:06:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6905c7a4aa1ef675825bc2ab56fd965a573ffb74'/>
<id>urn:sha1:6905c7a4aa1ef675825bc2ab56fd965a573ffb74</id>
<content type='text'>
commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream.

Changes since V1: fixed the description and added KASan warning.

In assoc_array_insert_into_terminal_node(), we call the
compare_object() method on all non-empty slots, even when they're
not leaves, passing a pointer to an unexpected structure to
compare_object(). Currently it causes an out-of-bound read access
in keyring_compare_object detected by KASan (see below). The issue
is easily reproduced with keyutils testsuite.
Only call compare_object() when the slot is a leave.

KASan warning:
==================================================================
BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
Read of size 8 by task keyctl/1655
=============================================================================
BUG kmalloc-192 (Not tainted): kasan: bad access detected
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647
	___slab_alloc+0x563/0x5c0
	__slab_alloc+0x51/0x90
	kmem_cache_alloc_trace+0x263/0x300
	assoc_array_insert+0xfd0/0x3a60
	__key_link_begin+0xfc/0x270
	key_create_or_update+0x459/0xaf0
	SyS_add_key+0x1ba/0x350
	entry_SYSCALL_64_fastpath+0x12/0x76
INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080
INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1

Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00  ...`............
Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff  ...`.......`....
Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
CPU: 0 PID: 1655 Comm: keyctl Tainted: G    B           4.5.0-rc4-kasan+ #291
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491
 ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969
 ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650
Call Trace:
 [&lt;ffffffff81b60491&gt;] dump_stack+0x85/0xc4
 [&lt;ffffffff815e2969&gt;] print_trailer+0xf9/0x150
 [&lt;ffffffff815e9454&gt;] object_err+0x34/0x40
 [&lt;ffffffff815ebe50&gt;] kasan_report_error+0x230/0x550
 [&lt;ffffffff819949be&gt;] ? keyring_get_key_chunk+0x13e/0x210
 [&lt;ffffffff815ec62d&gt;] __asan_report_load_n_noabort+0x5d/0x70
 [&lt;ffffffff81994cc3&gt;] ? keyring_compare_object+0x213/0x240
 [&lt;ffffffff81994cc3&gt;] keyring_compare_object+0x213/0x240
 [&lt;ffffffff81bc238c&gt;] assoc_array_insert+0x86c/0x3a60
 [&lt;ffffffff81bc1b20&gt;] ? assoc_array_cancel_edit+0x70/0x70
 [&lt;ffffffff8199797d&gt;] ? __key_link_begin+0x20d/0x270
 [&lt;ffffffff8199786c&gt;] __key_link_begin+0xfc/0x270
 [&lt;ffffffff81993389&gt;] key_create_or_update+0x459/0xaf0
 [&lt;ffffffff8128ce0d&gt;] ? trace_hardirqs_on+0xd/0x10
 [&lt;ffffffff81992f30&gt;] ? key_type_lookup+0xc0/0xc0
 [&lt;ffffffff8199e19d&gt;] ? lookup_user_key+0x13d/0xcd0
 [&lt;ffffffff81534763&gt;] ? memdup_user+0x53/0x80
 [&lt;ffffffff819983ea&gt;] SyS_add_key+0x1ba/0x350
 [&lt;ffffffff81998230&gt;] ? key_get_type_from_user.constprop.6+0xa0/0xa0
 [&lt;ffffffff828bcf4e&gt;] ? retint_user+0x18/0x23
 [&lt;ffffffff8128cc7e&gt;] ? trace_hardirqs_on_caller+0x3fe/0x580
 [&lt;ffffffff81004017&gt;] ? trace_hardirqs_on_thunk+0x17/0x19
 [&lt;ffffffff828bc432&gt;] entry_SYSCALL_64_fastpath+0x12/0x76
Memory state around the buggy address:
 ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
 ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
&gt;ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                        ^
 ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00
==================================================================

Signed-off-by: Jerome Marchand &lt;jmarchan@redhat.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>lib: sw842: select crc32</title>
<updated>2016-03-03T23:07:24+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-01-13T22:24:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=96ee50f3b366a0b547dfac776a43af15ccc322e0'/>
<id>urn:sha1:96ee50f3b366a0b547dfac776a43af15ccc322e0</id>
<content type='text'>
commit 5b57167749274961baf15ed1f05a4996b3ab0487 upstream.

The sw842 library code was merged in linux-4.1 and causes a very rare randconfig
failure when CONFIG_CRC32 is not set:

    lib/built-in.o: In function `sw842_compress':
    oid_registry.c:(.text+0x12ddc): undefined reference to `crc32_be'
    lib/built-in.o: In function `sw842_decompress':
    oid_registry.c:(.text+0x137e4): undefined reference to `crc32_be'

This adds an explict 'select CRC32' statement, similar to what the other users
of the crc32 code have. In practice, CRC32 is always enabled anyway because
over 100 other symbols select it.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Fixes: 2da572c959dd ("lib: add software 842 compression/decompression")
Acked-by: Dan Streetman &lt;ddstreet@ieee.org&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>
</entry>
<entry>
<title>lib/ucs2_string: Correct ucs2 -&gt; utf8 conversion</title>
<updated>2016-03-03T23:07:09+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.radix-linux.su/kernel/linux.git/commit/?id=9e8afc94ffae6f7ab9ba77308a9ab53aaf10335e'/>
<id>urn:sha1:9e8afc94ffae6f7ab9ba77308a9ab53aaf10335e</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>
</entry>
</feed>
