Bug 481658 - Backport partition table sanity checks to RHEL5
Backport partition table sanity checks to RHEL5
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Stefan Assmann
Red Hat Kernel QE team
Depends On:
Blocks: 533192 526775 557926
  Show dependency treegraph
Reported: 2009-01-26 16:38 EST by Bryn M. Reeves
Modified: 2010-10-23 03:13 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 03:39:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Backport partition checks to RHEL4's 2.6.9 (1.06 KB, patch)
2009-01-26 16:42 EST, Bryn M. Reeves
no flags Details | Diff
Backport partition checks to RHEL5's 2.6.18 (991 bytes, patch)
2009-03-10 14:44 EDT, Bryn M. Reeves
no flags Details | Diff
Backport partition checks to RHEL5's 2.6.18 - updated patch (1.05 KB, patch)
2009-05-18 03:59 EDT, Stefan Assmann
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0178 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.5 kernel security and bug fix update 2010-03-29 08:18:21 EDT

  None (edit)
Description Bryn M. Reeves 2009-01-26 16:38:00 EST
Description of problem:
Upstream added a couple of extra checks to fs/partitions/check.c since 2.6.9:

commit ac0d86f5809598ddcd6bfa0ea8245ccc910e9eac
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Wed Oct 15 22:04:21 2008 -0700

   block: sanitize invalid partition table entries
   We currently follow blindly what the partition table lies about the
   disk, and let the kernel create block devices which can not be accessed.
   Trying to identify the device leads to kernel logs full of:
     sdb: rw=0, want=73392, limit=28800
     attempt to access beyond end of device
   Here is an example of a broken partition table, where sda2 starts
   behind the end of the disk, and sdb3 is larger than the entire disk:
     Disk /dev/sdb: 14 MB, 14745600 bytes
     1 heads, 29 sectors/track, 993 cylinders, total 28800 sectors
        Device Boot      Start         End      Blocks   Id  System
     /dev/sdb1              29        7800        3886   83  Linux
     /dev/sdb2           37801       45601        3900+  83  Linux
     /dev/sdb3           15602       73402       28900+  83  Linux
     /dev/sdb4           23403       28796        2697   83  Linux
   The kernel creates these completely invalid devices, which can not be
   accessed, or may lead to other unpredictable failures:
     grep . /sys/class/block/sdb*/{start,size}
   With this patch, we ignore partitions which start behind the end of the disk,
   and limit partitions to the end of the disk if they pretend to be larger:
     grep . /sys/class/block/sdb*/{start,size}
   These warnings are printed to the kernel log:
     sdb: p2 ignored, start 37801 is behind the end of the disk
     sdb: p3 size 57801 limited to end of disk
   Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
   Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
   Cc: Jens Axboe <jens.axboe@oracle.com>
   Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
   Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 98bd34eaf1a7d1f2ed9c4e5d3a9664d3dcdd2159
Author: Mike Miller <mike.miller@hp.com>
Date:   Fri Jun 23 02:06:07 2006 -0700

    [PATCH] make kernel warn about incorrectly sized partitions
    Sometimes partitions claim to be larger than the reported capacity of a
    disk device.  This patch makes the kernel warn about those partitions.
    We still permit these patitions to be used.  Quoting Andries Brouwer
     Case 1: The kernel is mistaken about the size of the disk.  (There are
     commands to clip a disk to a certain capacity, there are jumpers to tell a
     disk that it should report a certain capacity etc.  Usually this is because
     of BIOS bugs.  In bad cases the machine will crash in the BIOS and hence fail
     to boot if the disk reports full capacity.) In such cases actually accessing
     the blocks of the partition may work fine, or may work fine after running an
     unclip utility.  I wrote "setmax" some years ago precisely for this reason.
     Case 2: There was a messy partition table (maybe just a rounding error) but
     the actual filesystem on the partition is contained in the physical disk.
     Now using the filesystem goes without problem.
     Case 3: Both partition and filesystem extend beyond the end of the disk.  In
     forensic or debugging situations one often uses a copy of the start of a
     disk.  Now access beyond the end gives an expected I/O error.
    Signed-off-by: Mike Miller <mike.miller@hp.com>
    Signed-off-by: Stephen Cameron <steve.cameron@hp.com>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index cd885b2..2ef313a 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -484,6 +484,10 @@ int rescan_partitions(struct gendisk *disk, struct block_device *bdev)
                sector_t from = state->parts[p].from;
                if (!size)
+               if (from + size > get_capacity(disk)) {
+                       printk(" %s: p%d exceeds device capacity\n",
+                               disk->disk_name, p);
+               }
                add_partition(disk, p, from, size);
                if (state->parts[p].flags)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create an invalid partition table (copy it from a larger "donor" device or use "advanced mode" in a partition editor)
2. Attach the device / reload partitions
3. Attempt do access the whole device on the invalid partition, e.g.:

$ dd if=/dev/sdc3 off=/dev/null
Actual results:
dd dies with an I/O error when it falls off the end of the device. dmesg fills with I/O failures.

Expected results:
No errors; partitions sizes should be limited to the size of the device on which they reside.

Additional info:
Comment 2 Bryn M. Reeves 2009-01-26 16:42:13 EST
Created attachment 330030 [details]
Backport partition checks to RHEL4's 2.6.9
Comment 8 Bryn M. Reeves 2009-03-10 14:44:01 EDT
Created attachment 334693 [details]
Backport partition checks to RHEL5's 2.6.18
Comment 11 Stefan Assmann 2009-05-18 03:59:06 EDT
Created attachment 344390 [details]
Backport partition checks to RHEL5's 2.6.18 - updated patch
Comment 16 RHEL Product and Program Management 2009-10-01 12:14:54 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 17 Don Zickus 2009-10-06 15:36:20 EDT
in kernel-2.6.18-168.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 19 Chris Ward 2010-02-11 05:24:44 EST
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.
Comment 23 Boris Ranto 2010-03-24 09:27:18 EDT
Verified in kernel 2.6.18-194.
If device end is behind the end of device, there is appropriate warning/error in log file and device is shortened to the end of file.
If device start is behind the end of device, kernel warns as about it in the log and device is not created in /dev.
Comment 24 errata-xmlrpc 2010-03-30 03:39:14 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.