1. 01 Jun, 2012 6 commits
    • James Bottomley's avatar
      PARISC: fix panic on prefetch(NULL) on PA7300LC · 63ce590e
      James Bottomley authored
      commit b3cb8674 upstream.
      
      Due to an errata, the PA7300LC generates a TLB miss interruption even on the
      prefetch instruction.  This means that prefetch(NULL), which is supposed to be
      a nop on linux actually generates a NULL deref fault.  Fix this by testing the
      address of prefetch against NULL before doing the prefetch.
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63ce590e
    • John David Anglin's avatar
      PARISC: fix crash in flush_icache_page_asm on PA1.1 · 2952561d
      John David Anglin authored
      commit 207f583d upstream.
      
      As pointed out by serveral people, PA1.1 only has a type 26 instruction
      meaning that the space register must be explicitly encoded.  Not giving an
      explicit space means that the compiler uses the type 24 version which is PA2.0
      only resulting in an illegal instruction crash.
      
      This regression was caused by
      
          commit f311847c
          Author: James Bottomley <James.Bottomley@HansenPartnership.com>
          Date:   Wed Dec 22 10:22:11 2010 -0600
      
              parisc: flush pages through tmpalias space
      Reported-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2952561d
    • James Bottomley's avatar
      PARISC: fix PA1.1 oops on boot · 34f3f91d
      James Bottomley authored
      commit 5e185581 upstream.
      
      All PA1.1 systems have been oopsing on boot since
      
      commit f311847c
      Author: James Bottomley <James.Bottomley@HansenPartnership.com>
      Date:   Wed Dec 22 10:22:11 2010 -0600
      
          parisc: flush pages through tmpalias space
      
      because a PA2.0 instruction was accidentally introduced into the PA1.1 TLB
      insertion interruption path when it was consolidated with the do_alias macro.
      Fix the do_alias macro only to use PA2.0 instructions if compiled for 64 bit.
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34f3f91d
    • Jeff Moyer's avatar
      block: don't mark buffers beyond end of disk as mapped · 37a84577
      Jeff Moyer authored
      commit 080399aa upstream.
      
      Hi,
      
      We have a bug report open where a squashfs image mounted on ppc64 would
      exhibit errors due to trying to read beyond the end of the disk.  It can
      easily be reproduced by doing the following:
      
      [root@ibm-p750e-02-lp3 ~]# ls -l install.img
      -rw-r--r-- 1 root root 142032896 Apr 30 16:46 install.img
      [root@ibm-p750e-02-lp3 ~]# mount -o loop ./install.img /mnt/test
      [root@ibm-p750e-02-lp3 ~]# dd if=/dev/loop0 of=/dev/null
      dd: reading `/dev/loop0': Input/output error
      277376+0 records in
      277376+0 records out
      142016512 bytes (142 MB) copied, 0.9465 s, 150 MB/s
      
      In dmesg, you'll find the following:
      
      squashfs: version 4.0 (2009/01/31) Phillip Lougher
      [   43.106012] attempt to access beyond end of device
      [   43.106029] loop0: rw=0, want=277410, limit=277408
      [   43.106039] Buffer I/O error on device loop0, logical block 138704
      [   43.106053] attempt to access beyond end of device
      [   43.106057] loop0: rw=0, want=277412, limit=277408
      [   43.106061] Buffer I/O error on device loop0, logical block 138705
      [   43.106066] attempt to access beyond end of device
      [   43.106070] loop0: rw=0, want=277414, limit=277408
      [   43.106073] Buffer I/O error on device loop0, logical block 138706
      [   43.106078] attempt to access beyond end of device
      [   43.106081] loop0: rw=0, want=277416, limit=277408
      [   43.106085] Buffer I/O error on device loop0, logical block 138707
      [   43.106089] attempt to access beyond end of device
      [   43.106093] loop0: rw=0, want=277418, limit=277408
      [   43.106096] Buffer I/O error on device loop0, logical block 138708
      [   43.106101] attempt to access beyond end of device
      [   43.106104] loop0: rw=0, want=277420, limit=277408
      [   43.106108] Buffer I/O error on device loop0, logical block 138709
      [   43.106112] attempt to access beyond end of device
      [   43.106116] loop0: rw=0, want=277422, limit=277408
      [   43.106120] Buffer I/O error on device loop0, logical block 138710
      [   43.106124] attempt to access beyond end of device
      [   43.106128] loop0: rw=0, want=277424, limit=277408
      [   43.106131] Buffer I/O error on device loop0, logical block 138711
      [   43.106135] attempt to access beyond end of device
      [   43.106139] loop0: rw=0, want=277426, limit=277408
      [   43.106143] Buffer I/O error on device loop0, logical block 138712
      [   43.106147] attempt to access beyond end of device
      [   43.106151] loop0: rw=0, want=277428, limit=277408
      [   43.106154] Buffer I/O error on device loop0, logical block 138713
      [   43.106158] attempt to access beyond end of device
      [   43.106162] loop0: rw=0, want=277430, limit=277408
      [   43.106166] attempt to access beyond end of device
      [   43.106169] loop0: rw=0, want=277432, limit=277408
      ...
      [   43.106307] attempt to access beyond end of device
      [   43.106311] loop0: rw=0, want=277470, limit=2774
      
      Squashfs manages to read in the end block(s) of the disk during the
      mount operation.  Then, when dd reads the block device, it leads to
      block_read_full_page being called with buffers that are beyond end of
      disk, but are marked as mapped.  Thus, it would end up submitting read
      I/O against them, resulting in the errors mentioned above.  I fixed the
      problem by modifying init_page_buffers to only set the buffer mapped if
      it fell inside of i_size.
      
      Cheers,
      Jeff
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Acked-by: default avatarNick Piggin <npiggin@kernel.dk>
      
      --
      
      Changes from v1->v2: re-used max_block, as suggested by Nick Piggin.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37a84577
    • Tejun Heo's avatar
      block: fix buffer overflow when printing partition UUIDs · 19e40444
      Tejun Heo authored
      commit 05c69d29 upstream.
      
      6d1d8050 "block, partition: add partition_meta_info to hd_struct"
      added part_unpack_uuid() which assumes that the passed in buffer has
      enough space for sprintfing "%pU" - 37 characters including '\0'.
      
      Unfortunately, b5af921e "init: add support for root devices
      specified by partition UUID" supplied 33 bytes buffer to the function
      leading to the following panic with stackprotector enabled.
      
        Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e
      
        [<ffffffff815e226b>] panic+0xba/0x1c6
        [<ffffffff81b14c7e>] ? printk_all_partitions+0x259/0x26xb
        [<ffffffff810566bb>] __stack_chk_fail+0x1b/0x20
        [<ffffffff81b15c7e>] printk_all_paritions+0x259/0x26xb
        [<ffffffff81aedfe0>] mount_block_root+0x1bc/0x27f
        [<ffffffff81aee0fa>] mount_root+0x57/0x5b
        [<ffffffff81aee23b>] prepare_namespace+0x13d/0x176
        [<ffffffff8107eec0>] ? release_tgcred.isra.4+0x330/0x30
        [<ffffffff81aedd60>] kernel_init+0x155/0x15a
        [<ffffffff81087b97>] ? schedule_tail+0x27/0xb0
        [<ffffffff815f4d24>] kernel_thread_helper+0x5/0x10
        [<ffffffff81aedc0b>] ? start_kernel+0x3c5/0x3c5
        [<ffffffff815f4d20>] ? gs_change+0x13/0x13
      
      Increase the buffer size, remove the dangerous part_unpack_uuid() and
      use snprintf() directly from printk_all_partitions().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarSzymon Gruszczynski <sz.gruszczynski@googlemail.com>
      Cc: Will Drewry <wad@chromium.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19e40444
    • Chris Metcalf's avatar
      tilegx: enable SYSCALL_WRAPPERS support · f2c927b9
      Chris Metcalf authored
      commit e6d9668e upstream.
      
      Some discussion with the glibc mailing lists revealed that this was
      necessary for 64-bit platforms with MIPS-like sign-extension rules
      for 32-bit values.  The original symptom was that passing (uid_t)-1 to
      setreuid() was failing in programs linked -pthread because of the "setxid"
      mechanism for passing setxid-type function arguments to the syscall code.
      SYSCALL_WRAPPERS handles ensuring that all syscall arguments end up with
      proper sign-extension and is thus the appropriate fix for this problem.
      
      On other platforms (s390, powerpc, sparc64, and mips) this was fixed
      in 2.6.28.6.  The general issue is tracked as CVE-2009-0029.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2c927b9
  2. 21 May, 2012 34 commits