linux.git/lib, branch v4.3-rc2

lib/string_helpers.c: fix infinite loop in string_get_size()

2015-09-18T04:16:07+00:00

Some string_get_size() calls (e.g.:
 string_get_size(1, 512, STRING_UNITS_10, ..., ...)
 string_get_size(15, 64, STRING_UNITS_10, ..., ...)
) result in an infinite loop. The problem is that if size is equal to
divisor[units]/blk_size and is smaller than divisor[units] we'll end
up with size == 0 when we start doing sf_cap calculations:

For string_get_size(1, 512, STRING_UNITS_10, ..., ...) case:
   ...
   remainder = do_div(size, divisor[units]); -> size is 0, remainder is 1
   remainder *= blk_size; -> remainder is 512
   ...
   size *= blk_size; -> size is still 0
   size += remainder / divisor[units]; -> size is still 0

The caller causing the issue is sd_read_capacity(), the problem was
noticed on Hyper-V, such weird size was reported by host when scanning
collides with device removal.  This is probably a separate issue worth
fixing, this patch is intended to prevent the library routine from
infinite looping.

Signed-off-by: Vitaly Kuznetsov 
Acked-by: James Bottomley 
Cc: Andy Shevchenko 
Cc: Rasmus Villemoes 
Cc: "K. Y. Srinivasan" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

zlib_deflate/deftree: remove bi_reverse()

2015-09-10T20:29:01+00:00

Remove bi_reverse() and use generic bitrev32() instead - it should have
better performance on some platforms.

Signed-off-by: yalin wang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/decompress_unlzma: Do a NULL check for pointer

2015-09-10T20:29:01+00:00

Compare pointer-typed values to NULL rather than 0.

The semantic patch that makes this change is available
in scripts/coccinelle/null/badzero.cocci.

Signed-off-by: Fabio Estevam 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/decompressors: use real out buf size for gunzip with kernel

2015-09-10T20:29:01+00:00

When loading x86 64bit kernel above 4GiB with patched grub2, got kernel
gunzip error.

| early console in decompress_kernel
| decompress_kernel:
|       input: [0x807f2143b4-0x807ff61aee]
|      output: [0x807cc00000-0x807f3ea29b] 0x027ea29c: output_len
| boot via startup_64
| KASLR using RDTSC...
|  new output: [0x46fe000000-0x470138cfff] 0x0338d000: output_run_size
|  decompress: [0x46fe000000-0x47007ea29b] <=== [0x807f2143b4-0x807ff61aee]
|
| Decompressing Linux... gz...
|
| uncompression error
|
| -- System halted

the new buffer is at 0x46fe000000ULL, decompressor_gzip is using
0xffffffb901ffffff as out_len.  gunzip in lib/zlib_inflate/inflate.c cap
that len to 0x01ffffff and decompress fails later.

We could hit this problem with crashkernel booting that uses kexec loading
kernel above 4GiB.

We have decompress_* support:
    1. inbuf[]/outbuf[] for kernel preboot.
    2. inbuf[]/flush() for initramfs
    3. fill()/flush() for initrd.
This bug only affect kernel preboot path that use outbuf[].

Add __decompress and take real out_buf_len for gunzip instead of guessing
wrong buf size.

Fixes: 1431574a1c4 (lib/decompressors: fix "no limit" output buffer length)
Signed-off-by: Yinghai Lu 
Cc: Alexandre Courbot 
Cc: Jon Medhurst 
Cc: Stephen Warren 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/test_kasan.c: make kmalloc_oob_krealloc_less more correctly

2015-09-10T20:29:01+00:00

In kmalloc_oob_krealloc_less, I think it is better to test
the size2 boundary.

If we do not call krealloc, the access of position size1 will still cause
out-of-bounds and access of position size2 does not.  After call krealloc,
the access of position size2 cause out-of-bounds.  So using size2 is more
correct.

Signed-off-by: Wang Long 
Cc: Andrey Ryabinin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/test_kasan.c: fix a typo

2015-09-10T20:29:01+00:00

Signed-off-by: Wang Long 
Cc: Andrey Ryabinin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string_helpers: rename "esc" arg to "only"

2015-09-10T20:29:01+00:00

To further clarify the purpose of the "esc" argument, rename it to "only"
to reflect that it is a limit, not a list of additional characters to
escape.

Signed-off-by: Kees Cook 
Suggested-by: Rasmus Villemoes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string_helpers: clarify esc arg in string_escape_mem

2015-09-10T20:29:01+00:00

The esc argument is used to reduce which characters will be escaped.  For
example, using " " with ESCAPE_SPACE will not produce any escaped spaces.

Signed-off-by: Kees Cook 
Cc: Andy Shevchenko 
Cc: Rasmus Villemoes 
Cc: Mathias Krause 
Cc: James Bottomley 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/bitmap.c: bitmap_parselist can accept string with whitespaces on head or tail

2015-09-10T20:29:01+00:00

In __bitmap_parselist we can accept whitespaces on head or tail during
every parsing procedure.  If input has valid ranges, there is no reason to
reject the user.

For example, bitmap_parselist(" 1-3, 5, ", &mask, nmaskbits).  After
separating the string, we get " 1-3", " 5", and " ".  It's possible and
reasonable to accept such string as long as the parsing result is correct.

Signed-off-by: Pan Xinhui 
Cc: Yury Norov 
Cc: Chris Metcalf 
Cc: Rasmus Villemoes 
Cc: Sudeep Holla 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/bitmap.c: fix a special string handling bug in __bitmap_parselist

2015-09-10T20:29:01+00:00

If string end with '-', for exapmle, bitmap_parselist("1,0-",&mask,
nmaskbits), It is not in a valid pattern, so add a check after loop.
Return -EINVAL on such condition.

Signed-off-by: Pan Xinhui 
Cc: Yury Norov 
Cc: Chris Metcalf 
Cc: Rasmus Villemoes 
Cc: Sudeep Holla 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds