1. 21 Jul, 2022 5 commits
  2. 19 Jul, 2022 2 commits
  3. 18 Jul, 2022 1 commit
  4. 12 Jul, 2022 1 commit
  5. 11 Jul, 2022 5 commits
  6. 06 Jul, 2022 2 commits
  7. 01 Jul, 2022 2 commits
  8. 30 Jun, 2022 2 commits
  9. 29 Jun, 2022 3 commits
  10. 28 Jun, 2022 4 commits
  11. 17 Jun, 2022 4 commits
  12. 16 Jun, 2022 3 commits
  13. 10 Jun, 2022 2 commits
  14. 09 Jun, 2022 2 commits
  15. 07 Jun, 2022 2 commits
    • Krzysztof Kozlowski's avatar
      dt-bindings: vendor-prefixes: document several vendors for Aspeed BMC boards · 72ca1900
      Krzysztof Kozlowski authored
      Add vendor prefixes for manufacturers of Aspeed SoC based BMC boards:
      ASrock, ByteDance, Ingrasys, Inventec and Quanta.  Move also bticino to
      proper alphabetical place.
      Signed-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20220529104928.79636-1-krzysztof.kozlowski@linaro.org
      72ca1900
    • Vaibhav Jain's avatar
      of: check previous kernel's ima-kexec-buffer against memory bounds · cbf9c4b9
      Vaibhav Jain authored
      Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
      ima-kexec-buffer lies outside the addressable memory range. This can result
      in a kernel panic if the new kernel is booted with 'mem=X' arg and the
      ima-kexec-buffer was allocated beyond that range by the previous kernel.
      The panic is usually of the form below:
      
      $ sudo kexec --initrd initrd vmlinux --append='mem=16G'
      
      <snip>
       BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
       Faulting instruction address: 0xc000000000837974
       Oops: Kernel access of bad area, sig: 11 [#1]
      <snip>
       NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
       LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
       Call Trace:
       [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
       [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
       [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
       [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
       [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
       [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
       [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
       Instruction dump:
       f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
       7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010
       ---[ end trace 0000000000000000 ]---
      
      Fix this issue by checking returned PFN range of previous kernel's
      ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.
      
      Fixes: 467d2782 ("powerpc: ima: get the kexec buffer passed by the previous kernel")
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Prakhar Srivastava <prsriva@linux.microsoft.com>
      Cc: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
      Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Ritesh Harjani <ritesh.list@gmail.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarVaibhav Jain <vaibhav@linux.ibm.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20220531041446.3334259-1-vaibhav@linux.ibm.com
      cbf9c4b9