linux-stable.git/block, branch linux-2.6.27.y

block: fail SCSI passthrough ioctls on partition devices

2012-02-11T14:40:55+00:00

commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
  and -ENOIOCTLCMD from sd_compat_ioctl. ]

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds 
[bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
 ENOTTY, so we must return ENOTTY directly]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Willy Tarreau

block: add and use scsi_blk_cmd_ioctl

2012-02-11T14:40:54+00:00

commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.

Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backport to 2.6.32 - adjust context]
Signed-off-by: Ben Hutchings 
[wt: slightly changed the interface to match 2.6.27's scsi_cmd_ioctl()
     which still needs the file pointer but has no mode parameter].

Signed-off-by: Willy Tarreau

block: add proper state guards to __elv_next_request

2012-02-11T14:38:37+00:00

commit 0a58e077eb600d1efd7e54ad9926a75a39d7f8ae upstream.

blk_cleanup_queue() calls elevator_exit() and after this, we can't
touch the elevator without oopsing.  __elv_next_request() must check
for this state because in the refcounted queue model, we can still
call it after blk_cleanup_queue() has been called.

This was reported as causing an oops attributable to scsi.

[WT: in 2.6.27, __elv_next_request() is in elevator.c]

Signed-off-by: James Bottomley 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

cfq-iosched: fix a rcu warning

2012-02-11T14:37:32+00:00

commit 3181faa85bda3dc3f5e630a1846526c9caaa38e3 upstream.

I got a rcu warnning at boot. the ioc->ioc_data is rcu_deferenced, but
doesn't hold rcu_read_lock.

Signed-off-by: Shaohua Li 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

cfq-iosched: fix locking around ioc->ioc_data assignment

2012-02-11T14:37:32+00:00

commit ab4bd22d3cce6977dc039664cc2d052e3147d662 upstream.

Since we are modifying this RCU pointer, we need to hold
the lock protecting it around it.

This fixes a potential reuse and double free of a cfq
io_context structure. The bug has been in CFQ for a long
time, it hit very few people but those it did hit seemed
to see it a lot.

Tracked in RH bugzilla here:

https://bugzilla.redhat.com/show_bug.cgi?id=577968

Credit goes to Paul Bolle for figuring out that the issue
was around the one-hit ioc->ioc_data cache. Thanks to his
hard work the issue is now fixed.

Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

block: check for proper length of iov entries in blk_rq_map_user_iov()

2010-12-09T21:24:15+00:00

commit 9284bcf4e335e5f18a8bc7b26461c33ab60d0689 upstream.

Ensure that we pass down properly validated iov segments before
calling into the mapping or copy functions.

Reported-by: Dan Rosenberg 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

bsg: fix incorrect device_status value

2010-10-29T04:04:16+00:00

commit 478971600e47cb83ff2d3c63c5c24f2b04b0d6a1 upstream.

bsg incorrectly returns sg's masked_status value for device_status.

[jejb: fix up expression logic]
Reported-by: Douglas Gilbert 
Signed-off-by: FUJITA Tomonori 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

Make SCSI SG v4 driver enabled by default and remove EXPERIMENTAL dependency, since udev depends on BSG

2009-08-16T21:26:33+00:00

commit 14d9fa352592582e457cf75022202766baac1348 upstream.

Make Block Layer SG support v4 the default, since recent udev versions
depend on this to access serial numbers and other low level info properly.

This should be backported to older kernels as well, since most distros have
enabled this for a long time.

Signed-off-by: John Stoffel 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

Enforce a minimum SG_IO timeout

2008-12-13T23:29:14+00:00

commit f2f1fa78a155524b849edf359e42a3001ea652c0 upstream.

There's no point in having too short SG_IO timeouts, since if the
command does end up timing out, we'll end up through the reset sequence
that is several seconds long in order to abort the command that timed
out.

As a result, shorter timeouts than a few seconds simply do not make
sense, as the recovery would be longer than the timeout itself.

Add a BLK_MIN_SG_TIMEOUT to match the existign BLK_DEFAULT_SG_TIMEOUT.

Suggested-by: Alan Cox 
Acked-by: Tejun Heo 
Acked-by: Jens Axboe 
Cc: Jeff Garzik 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

block: fix nr_phys_segments miscalculation bug

2008-11-20T22:54:47+00:00

commit 8677142710516d986d932d6f1fba7be8382c1fec upstream
backported by Nikanth Karthikesan  to the 2.6.27.y tree.

block: fix nr_phys_segments miscalculation bug

This fixes the bug reported by Nikanth Karthikesan :

http://lkml.org/lkml/2008/10/2/203

The root cause of the bug is that blk_phys_contig_segment
miscalculates q->max_segment_size.

blk_phys_contig_segment checks:

req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size

But blk_recalc_rq_segments might expect that req->biotail and the
previous bio in the req are supposed be merged into one
segment. blk_recalc_rq_segments might also expect that next_req->bio
and the next bio in the next_req are supposed be merged into one
segment. In such case, we merge two requests that can't be merged
here. Later, blk_rq_map_sg gives more segments than it should.

We need to keep track of segment size in blk_recalc_rq_segments and
use it to see if two requests can be merged. This patch implements it
in the similar way that we used to do for hw merging (virtual
merging).

Signed-off-by: FUJITA Tomonori 
Signed-off-by: Jens Axboe 
Cc: Nikanth Karthikesan 
Signed-off-by: Greg Kroah-Hartman