kernel_samsung_smdk4412/block, branch replicant-6.0

sg_write()/bsg_write() is not fit to be called under KERNEL_DS

2017-01-08T12:55:35+00:00

Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those.  Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.

Change-Id: I0d2f3b1ed4e763c559ecec98af32767360985e91
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro

block: fix use-after-free in seq file

2016-11-11T02:26:50+00:00

I got a KASAN report of use-after-free:

    ==================================================================
    BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
    Read of size 8 by task trinity-c1/315
    =============================================================================
    BUG kmalloc-32 (Not tainted): kasan: bad access detected
    -----------------------------------------------------------------------------

    Disabling lock debugging due to kernel taint
    INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
            ___slab_alloc+0x4f1/0x520
            __slab_alloc.isra.58+0x56/0x80
            kmem_cache_alloc_trace+0x260/0x2a0
            disk_seqf_start+0x66/0x110
            traverse+0x176/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a
    INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
            __slab_free+0x17a/0x2c0
            kfree+0x20a/0x220
            disk_seqf_stop+0x42/0x50
            traverse+0x3b5/0x860
            seq_read+0x7e3/0x11a0
            proc_reg_read+0xbc/0x180
            do_loop_readv_writev+0x134/0x210
            do_readv_writev+0x565/0x660
            vfs_readv+0x67/0xa0
            do_preadv+0x126/0x170
            SyS_preadv+0xc/0x10
            do_syscall_64+0x1a1/0x460
            return_from_SYSCALL_64+0x0/0x6a

    CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ #62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
     ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
     ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
     ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
    Call Trace:
     [] dump_stack+0x65/0x84
     [] print_trailer+0x10d/0x1a0
     [] object_err+0x2f/0x40
     [] kasan_report_error+0x221/0x520
     [] __asan_report_load8_noabort+0x3e/0x40
     [] klist_iter_exit+0x61/0x70
     [] class_dev_iter_exit+0x9/0x10
     [] disk_seqf_stop+0x3a/0x50
     [] seq_read+0x4b2/0x11a0
     [] proc_reg_read+0xbc/0x180
     [] do_loop_readv_writev+0x134/0x210
     [] do_readv_writev+0x565/0x660
     [] vfs_readv+0x67/0xa0
     [] do_preadv+0x126/0x170
     [] SyS_preadv+0xc/0x10

This problem can occur in the following situation:

open()
 - pread()
    - .seq_start()
       - iter = kmalloc() // succeeds
       - seqf->private = iter
    - .seq_stop()
       - kfree(seqf->private)
 - pread()
    - .seq_start()
       - iter = kmalloc() // fails
    - .seq_stop()
       - class_dev_iter_exit(seqf->private) // boom! old pointer

As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.

An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.

Change-Id: I41ee55505a213f99a92ce630885e6c31b4b60232
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe

block: separate priority boosting from REQ_META

2016-02-17T00:29:47+00:00

Add a new REQ_PRIO to let requests preempt others in the cfq I/O schedule,
and lave REQ_META purely for marking requests as metadata in blktrace.

All existing callers of REQ_META except for XFS are updated to also
set REQ_PRIO for now.

Backported to 3.0.x by Ketut Putu Kumajaya 

Change-Id: Iad5ba7a105438776f74788c0aedaf85210c613f9

Merge remote-tracking branch 'korg/linux-3.0.y' into cm-13.0

2015-11-10T19:01:25+00:00

Conflicts:
	crypto/algapi.c
	drivers/gpu/drm/i915/i915_debugfs.c
	drivers/gpu/drm/i915/intel_display.c
	drivers/video/fbmem.c
	include/linux/nls.h
	kernel/cgroup.c
	kernel/signal.c
	kernel/timeconst.pl
	net/ipv4/ping.c

Change-Id: I1f532925d1743df74d66bcdd6fc92f05c72ee0dd

block: do not pass disk names as format strings

2013-07-13T17:34:43+00:00

commit ffc8b30866879ed9ba62bd0a86fecdbd51cd3d19 upstream.

Disk names may contain arbitrary strings, so they must not be
interpreted as format strings.  It seems that only md allows arbitrary
strings to be used for disk names, but this could allow for a local
memory corruption from uid 0 into ring 0.

CVE-2013-2851

Signed-off-by: Kees Cook 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

block: avoid using uninitialized value in from queue_var_store

2013-04-12T16:18:09+00:00

commit c678ef5286ddb5cf70384ad5af286b0afc9b73e1 upstream.

As found by gcc-4.8, the QUEUE_SYSFS_BIT_FNS macro creates functions
that use a value generated by queue_var_store independent of whether
that value was set or not.

block/blk-sysfs.c: In function 'queue_store_nonrot':
block/blk-sysfs.c:244:385: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]

Unlike most other such warnings, this one is not a false positive,
writing any non-number string into the sysfs files indeed has
an undefined result, rather than returning an error.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: add sio iosched

2013-04-02T16:23:53+00:00

Change-Id: Iaa76975d4635d2f5c560d39fbf23919410e7e64f

block: add row iosched

2013-04-02T16:19:05+00:00

Change-Id: I01857784f0506a0b443dd01c801908e0beea5f66

Merge remote-tracking branch 'kernelorg/linux-3.0.y' into 3_0_64

2013-02-27T14:19:08+00:00

Conflicts:
	arch/arm/Kconfig
	arch/arm/include/asm/hwcap.h
	arch/arm/kernel/smp.c
	arch/arm/plat-samsung/adc.c
	drivers/gpu/drm/i915/i915_reg.h
	drivers/gpu/drm/i915/intel_drv.h
	drivers/mmc/core/sd.c
	drivers/net/tun.c
	drivers/net/usb/usbnet.c
	drivers/regulator/max8997.c
	drivers/usb/core/hub.c
	drivers/usb/host/xhci.h
	drivers/usb/serial/qcserial.c
	fs/jbd2/transaction.c
	include/linux/migrate.h
	kernel/sys.c
	kernel/time/timekeeping.c
	lib/genalloc.c
	mm/memory-failure.c
	mm/memory_hotplug.c
	mm/mempolicy.c
	mm/page_alloc.c
	mm/vmalloc.c
	mm/vmscan.c
	mm/vmstat.c
	scripts/Kbuild.include

Change-Id: I91e2d85c07320c7ccfc04cf98a448e89bed6ade6

scsi: Silence unnecessary warnings about ioctl to partition

2012-12-10T18:45:08+00:00

commit 6d9359280753d2955f86d6411047516a9431eb51 upstream.

Sometimes, warnings about ioctls to partition happen often enough that they
form majority of the warnings in the kernel log and users complain. In some
cases warnings are about ioctls such as SG_IO so it's not good to get rid of
the warnings completely as they can ease debugging of userspace problems
when ioctl is refused.

Since I have seen warnings from lots of commands, including some proprietary
userspace applications, I don't think disallowing the ioctls for processes
with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.

Acked-by: Paolo Bonzini 
CC: James Bottomley 
CC: linux-scsi@vger.kernel.org
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Cc: Satoru Takeuchi 
Signed-off-by: Greg Kroah-Hartman