From: Greg Kroah-Hartman Date: Tue, 22 Jul 2025 13:17:00 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v6.1.147~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=dc837b8c5ab7e1521bac9d8ce06532a6d49a19e5;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch --- diff --git a/queue-6.6/nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch b/queue-6.6/nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch new file mode 100644 index 0000000000..95f69d17b6 --- /dev/null +++ b/queue-6.6/nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch @@ -0,0 +1,99 @@ +From 2d7521aa26ec2dc8b877bb2d1f2611a2df49a3cf Mon Sep 17 00:00:00 2001 +From: "Michael C. Pratt" +Date: Wed, 16 Jul 2025 15:42:10 +0100 +Subject: nvmem: layouts: u-boot-env: remove crc32 endianness conversion + +From: Michael C. Pratt + +commit 2d7521aa26ec2dc8b877bb2d1f2611a2df49a3cf upstream. + +On 11 Oct 2022, it was reported that the crc32 verification +of the u-boot environment failed only on big-endian systems +for the u-boot-env nvmem layout driver with the following error. + + Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88) + +This problem has been present since the driver was introduced, +and before it was made into a layout driver. + +The suggested fix at the time was to use further endianness +conversion macros in order to have both the stored and calculated +crc32 values to compare always represented in the system's endianness. +This was not accepted due to sparse warnings +and some disagreement on how to handle the situation. +Later on in a newer revision of the patch, it was proposed to use +cpu_to_le32() for both values to compare instead of le32_to_cpu() +and store the values as __le32 type to remove compilation errors. + +The necessity of this is based on the assumption that the use of crc32() +requires endianness conversion because the algorithm uses little-endian, +however, this does not prove to be the case and the issue is unrelated. + +Upon inspecting the current kernel code, +there already is an existing use of le32_to_cpu() in this driver, +which suggests there already is special handling for big-endian systems, +however, it is big-endian systems that have the problem. + +This, being the only functional difference between architectures +in the driver combined with the fact that the suggested fix +was to use the exact same endianness conversion for the values +brings up the possibility that it was not necessary to begin with, +as the same endianness conversion for two values expected to be the same +is expected to be equivalent to no conversion at all. + +After inspecting the u-boot environment of devices of both endianness +and trying to remove the existing endianness conversion, +the problem is resolved in an equivalent way as the other suggested fixes. + +Ultimately, it seems that u-boot is agnostic to endianness +at least for the purpose of environment variables. +In other words, u-boot reads and writes the stored crc32 value +with the same endianness that the crc32 value is calculated with +in whichever endianness a certain architecture runs on. + +Therefore, the u-boot-env driver does not need to convert endianness. +Remove the usage of endianness macros in the u-boot-env driver, +and change the type of local variables to maintain the same return type. + +If there is a special situation in the case of endianness, +it would be a corner case and should be handled by a unique "compatible". + +Even though it is not necessary to use endianness conversion macros here, +it may be useful to use them in the future for consistent error printing. + +Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables") +Reported-by: INAGAKI Hiroshi +Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: "Michael C. Pratt" +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20250716144210.4804-1-srini@kernel.org +[ applied changes to drivers/nvmem/u-boot-env.c after code was moved from drivers/nvmem/layouts/u-boot-env.c ] +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvmem/u-boot-env.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/nvmem/u-boot-env.c ++++ b/drivers/nvmem/u-boot-env.c +@@ -132,7 +132,7 @@ static int u_boot_env_parse(struct u_boo + size_t crc32_data_offset; + size_t crc32_data_len; + size_t crc32_offset; +- __le32 *crc32_addr; ++ uint32_t *crc32_addr; + size_t data_offset; + size_t data_len; + size_t dev_size; +@@ -183,8 +183,8 @@ static int u_boot_env_parse(struct u_boo + goto err_kfree; + } + +- crc32_addr = (__le32 *)(buf + crc32_offset); +- crc32 = le32_to_cpu(*crc32_addr); ++ crc32_addr = (uint32_t *)(buf + crc32_offset); ++ crc32 = *crc32_addr; + crc32_data_len = dev_size - crc32_data_offset; + data_len = dev_size - data_offset; + diff --git a/queue-6.6/series b/queue-6.6/series index 2d767cffab..a932c41241 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -108,3 +108,4 @@ asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch revert-selftests-bpf-adjust-dummy_st_ops_success-to-detect-additional-error.patch revert-selftests-bpf-dummy_st_ops-should-reject-0-for-non-nullable-params.patch i2c-omap-fix-deprecated-of_property_read_bool-use.patch +nvmem-layouts-u-boot-env-remove-crc32-endianness-conversion.patch