1. 07 10月, 2013 1 次提交
    • J
      MIPS: stack protector: Fix per-task canary switch · 8b3c569a
      James Hogan 提交于
      Commit 1400eb65 (MIPS: r4k,octeon,r2300: stack protector: change canary
      per task) was merged in v3.11 and introduced assembly in the MIPS resume
      functions to update the value of the current canary in
      __stack_chk_guard. However it used PTR_L resulting in a load of the
      canary value, instead of PTR_LA to construct its address. The value is
      intended to be random but is then treated as an address in the
      subsequent LONG_S (store).
      
      This was observed to cause a fault and panic:
      
      CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
      Oops[#1]:
      ...
      $24   : 139fea20 1e1f7cb6
      ...
      Call Trace:
      [<8000cc0c>] resume+0xac/0x118
      [<8034f2a4>] __schedule+0x5f8/0x78c
      [<8034f4e0>] schedule_preempt_disabled+0x20/0x2c
      [<80348eec>] rest_init+0x74/0x84
      [<804dc990>] start_kernel+0x43c/0x454
      Code: 3c18804b  8f184030  8cb901f8 <af190000> 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc
      
      This can also be forced by modifying
      arch/mips/include/asm/stackprotector.h so that the default
      __stack_chk_guard value is more likely to be a bad (or unaligned)
      pointer.
      
      Fix it to use PTR_LA instead, to load the address of the canary value,
      which the LONG_S can then use to write into it.
      
      Reported-by: bobjones (via #mipslinux on IRC)
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Gregory Fong <gregory.0xf0@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/6026/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8b3c569a
  2. 01 7月, 2013 1 次提交
  3. 01 2月, 2013 1 次提交
  4. 29 12月, 2012 1 次提交
  5. 19 7月, 2012 1 次提交
  6. 06 4月, 2011 1 次提交
  7. 18 9月, 2009 1 次提交
  8. 20 4月, 2007 1 次提交
  9. 17 3月, 2007 1 次提交
  10. 01 7月, 2006 1 次提交
  11. 10 9月, 2005 1 次提交
  12. 05 9月, 2005 1 次提交
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4