kernel/linux.git/drivers/firmware, branch v4.17.1

firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()

2018-05-25T03:36:45+00:00

qcom_scm_call_atomic1() can crash with a NULL pointer dereference at qcom_scm_call_atomic1+0x30/0x48. disassembly of qcom_scm_call_atomic1(): ... <0xc08d73b0 <+12>: ldr r3, [r12] ... (no instruction explicitly modifies r12) 0xc08d73cc <+40>: smc 0 ... (no instruction explicitly modifies r12) 0xc08d73d4 <+48>: ldr r3, [r12] <- crashing instruction ... Since the first ldr is successful, and since r12 isn't explicitly modified by any instruction between the first and the second ldr, it must have been modified by the smc call, which is ok, since r12 is caller save according to the AAPCS. Add r12 to the clobber list so that the compiler knows that the callee potentially overwrites the value in r12. Clobber descriptions may not in any way overlap with an input or output operand. Signed-off-by: Niklas Cassel Reviewed-by: Bjorn Andersson Reviewed-by: Stephen Boyd Signed-off-by: Andy Gross

Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2018-05-20T17:36:52+00:00

Pull EFI fixes from Thomas Gleixner: - Use explicitely sized type for the romimage pointer in the 32bit EFI protocol struct so a 64bit kernel does not expand it to 64bit. Ditto for the 64bit struct to avoid the reverse issue on 32bit kernels. - Handle randomized tex offset correctly in the ARM64 EFI stub to avoid unaligned data resulting in stack corruption and other hard to diagnose wreckage. * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/libstub/arm64: Handle randomized TEXT_OFFSET efi: Avoid potential crashes, fix the 'struct efi_pci_io_protocol_32' definition for mixed mode

efi/libstub/arm64: Handle randomized TEXT_OFFSET

2018-05-19T06:07:56+00:00

When CONFIG_RANDOMIZE_TEXT_OFFSET=y, TEXT_OFFSET is an arbitrary multiple of PAGE_SIZE in the interval [0, 2MB). The EFI stub does not account for the potential misalignment of TEXT_OFFSET relative to EFI_KIMG_ALIGN, and produces a randomized physical offset which is always a round multiple of EFI_KIMG_ALIGN. This may result in statically allocated objects whose alignment exceeds PAGE_SIZE to appear misaligned in memory. This has been observed to result in spurious stack overflow reports and failure to make use of the IRQ stacks, and theoretically could result in a number of other issues. We can OR in the low bits of TEXT_OFFSET to ensure that we have the necessary offset (and hence preserve the misalignment of TEXT_OFFSET relative to EFI_KIMG_ALIGN), so let's do that. Reported-by: Kim Phillips Tested-by: Kim Phillips [ardb: clarify comment and commit log, drop unneeded parens] Signed-off-by: Mark Rutland Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 6f26b3671184c36d ("arm64: kaslr: increase randomization granularity") Link: http://lkml.kernel.org/r/20180518140841.9731-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

Merge tag 'scmi-fixes-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into fixes

2018-05-14T08:05:00+00:00

SCMI fix for v4.17 A single patch to ensure that the scmi device is not used for setting up scmi handle after it's freed(fixes use after free). * tag 'scmi-fixes-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Use after free in scmi_create_protocol_device() Signed-off-by: Olof Johansson

firmware: arm_scmi: Use after free in scmi_create_protocol_device()

2018-05-08T17:03:47+00:00

We need to return here instead of setting up the freed sdev device as a transport. Fixes: 907b6d14911d ("firmware: arm_scmi: add per-protocol channels support using idr objects") Signed-off-by: Dan Carpenter Signed-off-by: Sudeep Holla

firmware: arm_scmi: remove redundant null check on array

2018-04-16T09:15:58+00:00

The null check on clk->name is redundant since name is a char array and can never be null, so the check is always true. Remove it. Detected by CoverityScan, CID#1466117 ("Array compared against 0") Signed-off-by: Colin Ian King Signed-off-by: Sudeep Holla

Merge branch 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging

2018-04-13T23:32:16+00:00

Pull dmi updates from Jean Delvare. * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: firmware: dmi_scan: Use lowercase letters for UUID firmware: dmi_scan: Add DMI_OEM_STRING support to dmi_matches firmware: dmi_scan: Fix UUID length safety check

firmware: dmi_scan: Use lowercase letters for UUID

2018-04-13T13:37:59+00:00

RFC 4122 asks for letters a-f in UUID to be lowercase. Follow this recommendation. Suggested by Paul Dagnelie at: https://savannah.nongnu.org/bugs/index.php?53569 Signed-off-by: Jean Delvare

firmware: dmi_scan: Add DMI_OEM_STRING support to dmi_matches

2018-04-13T13:37:59+00:00

OEM strings are defined by each OEM and they contain customized and useful OEM information. Supporting it provides more flexible uses of the dmi_matches function. Signed-off-by: Alex Hung Signed-off-by: Jean Delvare

firmware: dmi_scan: Fix UUID length safety check

2018-04-13T13:37:59+00:00

The test which ensures that the DMI type 1 structure is long enough to hold the UUID is off by one. It would fail if the structure is exactly 24 bytes long, while that's sufficient to hold the UUID. I don't expect this bug to cause problem in practice because all implementations I have seen had length 8, 25 or 27 bytes, in line with the SMBIOS specifications. But let's fix it still. Signed-off-by: Jean Delvare Fixes: a814c3597a6b ("firmware: dmi_scan: Check DMI structure length") Reviewed-by: Mika Westerberg